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 _______________________________________________ cabal-devel mailing list [email protected] http://www.haskell.org/mailman/listinfo/cabal-devel
