Re: trouble with Debian package ghc5

2002-05-29 Thread Alastair Reid


> 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

2002-05-29 Thread Ken Shan

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

2002-05-28 Thread Norman Ramsey

 > 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



RE: trouble with Debian package ghc5

2002-05-28 Thread Simon Marlow

> >>>
> 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

2002-05-28 Thread Michael Weber

* Norman Ramsey <[EMAIL PROTECTED]> [2002-05-27T19:12-0400]:
> I'm trying to compile some Haskell code using Debian package ghc5,
> and it fails to find -lreadline at link time.  Looks like a config
> problem because hte library is sitting there in /lib.

You also need the libreadline4-dev package to compile stuff against
readline (but see below).  Can you please check whether it is
installed?

> I'm cc-ing the GHC bug list even though this looks to me like a Debian
> problem.

>From looking at http://bugs.debian.org/134950, it _seemed_ to me only
ghc package util needed readline to link, and that wouldn't
necessarily warrant a dependency on libreadline*-dev.  Quoting Debian
policy:

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

Comments?


Cheers,
Michael
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs