WARNING: package dependencies

[Duncan Coutts]

On Tue, 2005-05-10 at 10:51 +0100, Simon Marlow wrote:
> Yes, the module overlap restriction has started to bite us.  It now
> turns out that you can't build GHC from CVS if you have wxHaskell
> installed.
>
> Why?  Because wxHaskell depends on some older non-hierarchical packages
> (util in particular, which itself depends on lang).  These package
> populate the top-level module namespace, and steal a bunch of module
> names that you might want to use in your program.

There are a few libs that do this and it makes them essentially
unpackagable when using ghc 6.4. Not because of conflicts with ghc
itself but just conflicts with each other and totally unrelated
packages.

Just to make it clear to people how annoying it is, suppose I create a
library with this cabal description:

name: dummy
version: 1.0
depends: util-1.0
exposed: True

and then I register this package (to show the problem, this package
doesn't need to expose any modules or contain any object code)

$ ghc-pkg register dummy.cabal --user

Now if we try to compile any package that contains a module called
GetOpt (and lets face it there are dozens of programs that have made
local copies of this module):

GetOpt.hs:
module GetOpt where
-- module needn't have any code in it

Now if we try to compile it:

$ ghc-6.4 -c GetOpt.hs

GetOpt.hs:1:0
    Module `GetOpt` is a mamber of package util-1.0
    To compile this module, please use -ignore-package util-1.0.

So what this means is that by having *any* package registered on the
system that is exposed by default and depends on the old util package
from hslibs, then *any* other program or library that you try to compile
that has a GetOpt module (and there are lots of those) will not work.

We discovered this in Gentoo, when after installing Cabal-0.5 (which is
exposed by default and uses the util package), compiling happy failed.

Our intrim policy in Gentoo Haskell packaging land is that we cannot
package any library that is exposed by default and depends on any of the
old hslibs packages because it will cause compile failures in unrelated
programs. (We didn't realise wxhaskell did this too)

> Thoughts?

Ditch hslibs asap!

We can probably draw up a list of the packages we know about that do
this.

Duncan