Simon Marlow wrote:

1. Package builders should be careful about dependencies. Don't depend on any non-hierarchical packages from an exposed package. Daan - can you fix wxHaskell?

Yes, I probably can -- I guess it is time to move forward and forget about compatability with older ghc's (< 6.2.2) However, I don't really understand what is wrong and what to fix :-) (should I remove -package util and qualify explicitly in the code?) I can probably figure it out from the docs but maybe it would help if someone could add some "simple guidelines for package writers" documentation that would tell concretely what is good practice (and what is bad practice). All the best, -- Daan.

2. The GHC build could start using -fignore-all-packages to insulate itself from the environment (or, simpler but more hacky: -ignore-package lang). This isn't a *solution* as such, because the problem affects everyone, not just us.

3. We could put some safeguards in place to avoid this happening in the future, e.g. warnings from Cabal and/or ghc-pkg.

4. Cabal needs to start using -fignore-all-packages. Isaac?

Thoughts?

Cheers, Simon _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

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

Jhc also has been running afoul of this problem. I am not sure what the best solution is. Personally, I think that no cabal user built packages should be installed unhidden, as any has the possibility of breaking something that previously worked. Users should have to specifically request what they want with -package arguments for anything other than 'core' packages. I know it is not ideal, but i don't know another solution without lifting the naming restriction.... John -- John Meacham - ⑆repetae.net⑆john⑈