Dependencies/backwards compatibility in Hackage

[Isaac Jones]

Duncan Coutts <duncan.coutts at worc.ox.ac.uk> writes:

(snip)
>> 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.

peace,

  isaac