Re: trouble with Debian package ghc5
On 2002-05-28T14:50:22-0400, Norman Ramsey wrote: I _could_ make readline a hard dependency of ghc, but this is somehow not satisfactory. I'd rather like readline to be out-factored to its own package (I know, this would break other Haskell programs, but it's arguably easy-to-fix breakage...). Comments? For a newbie like me, it would be useful to have a `virtual' package ghc-util for `ghc programs that need util'. This could then require libreadline4-dev. The key is that something show up in dpkg --list ghc* Otherwise the need for libreadline4-dev is not obvious to the amateur. This dependency on libreadline4-dev seems to be a special case of a more general issue, namely how to handle packages in the GHC sense in the Debian packaging system. The way Perl module code is packaged for Debian seems to be quite sophisticated: Perl packages tend to correspond to individual Debian packages, so if a Perl program packaged for Debian uses a certain module, only that module (roughly speaking) needs to be installed, and will be automatically. Ideally, GHC packages would be handled in a similar way, but is it worth the trouble? - On one hand, since GHC does not yet support dynamic linking, programs compiled by GHC do not depend on Haskell modules or GHC packages. - On the other hand, there are relatively few GHC packages. (And Norman, welcome to Debian :) -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig You can't spell Chung-chieh without the Hun. msg04858/pgp0.pgp Description: PGP signature
Re: trouble with Debian package ghc5
This dependency on libreadline4-dev seems to be a special case of a more general issue, namely how to handle packages in the GHC sense in the Debian packaging system. The way Perl module code is packaged for Debian seems to be quite sophisticated: Perl packages tend to correspond to individual Debian packages, so if a Perl program packaged for Debian uses a certain module, only that module (roughly speaking) needs to be installed, and will be automatically. Ideally, GHC packages would be handled in a similar way, but is it worth the trouble? My personal inclination would be to do as Perl does: have many Debian packages with just one or two GHC packages each plus one or more dummy packages corresponding to top level directories in the hslibs tree. One potential problem with this is that GHC packages have unusually strong connections with each other. The problem is that GHC does a lot of cross-module inlining so if GHC package A imports GHC package B then the compiled form of A (i.e., the Debian package) will depend not on B but on the particular version of B that it was compiled against (and the version of GHC used to compile A and B). Changes to B which leave the API and semantics unchanged might still break A. One could get round this in the Debian package by requiring particular version numbers in the packages (it's more usual for a Debian package to depend on ranges of version numbers such as = 3.2.1) - at the cost of making the restrictions on source distributions a bit stronger then they have to be. Note that there's really no way to avoid this problem: tomorrow some Haskell hacker could come along with a cool Haskell library that they don't want to add to the hslibs collection but which they want to release as a Debian package. They'll be faced with exactly this problem. (This problem may already exist: are there separate packages for the BSD and GPL'd parts of the hslibs tree.) -- Alastair Reid[EMAIL PROTECTED]http://www.cs.utah.edu/~reid/ ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: trouble with Debian package ghc5
7.2. Binary Dependencies - `Depends', `Recommends', `Suggests', `Enhances', `Pre-Depends' -- -- [...] The meaning of the five dependency fields is as follows: `Depends' [...] The `Depends' field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality. with significant amount of functionality being the key phrase. So Depends: is a weak dependency, not an absolute one (whether this is good or nor is debatable...). However, it seems you are right: whenever _some_ ghc package needs util, it will implicitly depend on libreadline being installed, even if readline is never really linked to. So, what can be done? The hot-fix is to install libreadline4-dev. I _could_ make readline a hard dependency of ghc, but this is somehow not satisfactory. I'd rather like readline to be out-factored to its own package (I know, this would break other Haskell programs, but it's arguably easy-to-fix breakage...). Personally, I would just add the dependency - I'm sure libreadline4-dev is small, and the debian package system is good at installing dependencies smoothly and transparently. It would be one less stumbling block for users. However, it does seem to be contrary to the Debian guidelines you quoted. So, it's up to you. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: trouble with Debian package ghc5
However, it seems you are right: whenever _some_ ghc package needs util, it will implicitly depend on libreadline being installed, even if readline is never really linked to. So, what can be done? The hot-fix is to install libreadline4-dev. Done. Works. Thanks. I _could_ make readline a hard dependency of ghc, but this is somehow not satisfactory. I'd rather like readline to be out-factored to its own package (I know, this would break other Haskell programs, but it's arguably easy-to-fix breakage...). Comments? For a newbie like me, it would be useful to have a `virtual' package ghc-util for `ghc programs that need util'. This could then require libreadline4-dev. The key is that something show up in dpkg --list ghc* Otherwise the need for libreadline4-dev is not obvious to the amateur. Norman ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
