On Tue, Mar 15, 2005 at 02:48:57PM -0600, John Goerzen wrote:
However, the new hugs is in sid now, and I have seen some incompatibilities between existing code and hugs.
It will be a nightmare to maintain source packages intended to be built with both hugs and ghc, and make them usable with both the new hugs and ghc 6.2. So I for one would welcome ghc 6.4 in sid ASAP.
Isaac, are there other advantages to having the new hugs in sarge without the new ghc/nhc98 that outweigh this problems, or should we file a dummy RC bug to keep it out of sarge until ghc 6.4 and nhc98 1.18 are ready to go in?
Should the ghc6 package provide libghc6-$foo-dev for each of the following?: rts, base, haskell98, template-haskell, unix, Cabal, parsec, haskell-src, network, QuickCheck, HUnit, mtl, fgl, X11, HGL, stm, readline, (lang), (concurrent), (posix), (util), (data), (text), (net), (hssource) (are the ones in parentheses deprecated? (from ghc-pkg -l output))
I would say there is no need to do that, since we can just depend on ghc and get the right thing, like we do now.
But shouldn't the tool to make debs from cabal packages automatically build-dep on things the cabal package says it needs? Doing the above would mean we don't need to special case it for that list.
My opinion is I shouldn't do the split+rename, but should provide everything not in parentheses (although I'm not sure about rts).
I don't think you really need to. A Provide is only useful if there are several ways to satisfy a dependency, which there really aren't here.
This would also mean things would keep on working if (in at least one case, when) bits get split out from ghc6 into their own package.
Thanks Ian