Dependencies/backwards compatibility in Hackage
ijones at syntaxpolice.org
Sun Feb 4 23:29:15 EST 2007
Duncan Coutts <duncan.coutts at worc.ox.ac.uk> writes:
>> We can ourselves modify packages so that their version dependency is
>> more accurate than upstream knows them to be :)
> It's for issues like this (ie creating a distribution) that having
> the .cabal file outside the .tar.gz file is a bonus.
> Let me compare to Gentoo: we provide a distribution of Haskell packages
> that we test as a group and know that they work together. We test stuff
> and make sure that the dependencies are sufficiently tight so that
> things don't break on users' systems. We have an .ebuild file for each
> package. For a haskell package this obviously duplicates most of the
> information in the .cabal file, however it gives us an opportunity to
> make slight corrections.
> The analogy in hackage is that the .cabal file outside the .tar.gz
> package can serve as the place where the distributors can 'fix' things.
> One example of this is the "tested-with:" field, another might be
> changing "build-depends:" to more tightly constrain version numbers.
Debian maintains diffs between the upstream version and the Debian
version. It would be nice to do this with darcs instead.
What I just did for HAppS, for instance, was update the .cabal file
with a description and such, then did a darcs record and forwarded the
.cabal file upstream, as well as modifying it within the .tarball that
I intend to upload.
What would be nice is if this were somehow integrated with darcs, so
that I can do a "darcs send" such changes to hackage, which would
relay it upstream, as well as keep track of the differences between
the upstream version and the Hackage version.
More information about the cabal-devel