Dependencies/backwards compatibility in Hackage

[Duncan Coutts]

On Sat, 2007-02-03 at 12:37 -0800, Isaac Jones wrote:
> The way I propose to solve this version incompatibility problem in the
> short term is to use the "testing" hackage repository to collect
> packages that are known to work together.  For instance, we could put
> haxml 1.17 in and only allow things that compile with that version.
> unstable can still have stuff that only compiles w/ 1.13, but if an
> author wants their tool to be in "testing", then they have to fix it
> up to be compatible.  (Or we might decide that 1.13 is a better
> version to have in testing.)
> 
> This will encouarage people to update their packages with a collection
> of dependencies that are somewhat "blessed", even if that blessing is
> a little arbitrary.
> 
> 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.

Duncan