RE: exposed package exposes dependent packages
On 06 April 2005 00:06, Duncan Coutts wrote: On Tue, 2005-04-05 at 23:34 +0100, Simon Marlow wrote: Well it turns out that we had another package installed that depends on the util package (cabal-0.5 as it happens) and that package is exposed by default. It seems that this implicitly exposes the util package. This is the right behaviour, although I agree it's a little confusing. The util package has not been exposed as a result of being depended on by cabal-0.5, but GHC has correctly inferred that it is part of the program, and so its modules cannot clash with any others in the program. But it's not part of the program. In our test program we do not import any module from the dummy package (which is the exposed package that depends on util). Our example was compiling happy. happy does not import anything from cabal-0.5 and yet it was hit by this problem. Unless we consider 'part of the program' to be all modules in all exposed packages (and all modules in 'efectively exposed' packages like util via the cabal-0.5 dep). You're asking GHC to decide which modules the program depends on, in order to figure out which packages are part of the program, rather than just starting from the list of exposed packages. Hmm, that might be possible... we could eagerly report module clashes in the exposed packages, but only report module clashes in the hidden packages when we know which ones are required. If this is not a bug, the only thing we can do is make sure we never create an ebuild for anything that installs an exposed package that depends on one of the old hslibs packages. Otherwise several other unrelated programs will fail to build. The documentation does describe this (section 4.8.1): There must be no overlaps in the modules provided by all of the exposed packages, and the packages they depend on, and so on. it doesn't mention the modules of the program though. Perhaps it should, I'm open to suggestions for better wording. So is it all modules provided by exposed packages or all modules included (directly or indirectly) in the program? It is: modules in the program (or current package) + modules from exposed packages + modules from all packages transitively reachable from the dependencies of the exposed packages. It would be nice if the error message said something like util-1.0 is included because it is a dependency of That would help. We were left wondering how on earth util was getting included into the program. I'm surprised that you could use -ignore-package util, I would have expected that to cause an error due to the dependency from cabal to util. That might be a bug - can you confirm? Yes indeed. Until recently we compiled happy with -ignore-package util to work around this issue. Our new solution is to declare cabal-0.5 to be incompatible with GHC 6.4. Ah, I remember now: -ignore-package also magically ignores all packages that depend on the ignored package. It was done this way so that you could recompile a package down at the bottom of the dependency graph (eg. base) without having to know all the packages that currently depend on it. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: exposed package exposes dependent packages
Our example was compiling happy. happy does not import anything from cabal-0.5 and yet it was hit by this problem. Unless we consider 'part of the program' to be all modules in all exposed packages (and all modules in 'efectively exposed' packages like util via the cabal-0.5 dep). You're asking GHC to decide which modules the program depends on, in order to figure out which packages are part of the program, rather than just starting from the list of exposed packages. Hmm, that might be possible... we could eagerly report module clashes in the exposed packages, but only report module clashes in the hidden packages when we know which ones are required. This sounds like a good compromise to me. It would allow to have some packages exposed which are not particularly well-behaved (i.e., pollute the name space), but you pay the price only when you're actually using the package. The current situation is unfortunately very fragile. An exposed package that is accidentally added to the system can break the compilation of completely unrelated programs. It'd be great if you could make this change in ghc. Cheers, Andres ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: exposed package exposes dependent packages
On 05 April 2005 21:33, Duncan Coutts wrote: Over in Gentoo Haskell packaging land, while trying to get all our progs and libs to work with GHC 6.4, we came across a couple programs that were failing to compile with this error message: GetOpt.lhs:1:0: Module `GetOpt' is a member of package util-1.0. To compile this module, please use -ignore-package util-1.0. Indeed applying the fix suggested in the error message works but I don't think it is right. $ ghc-pkg field util exposed reports as we know that the old util package is not exposed by default (since it does not use hierarchical module names) So how could the GetOpt module we're trying to compile possibly clash with the GetOpt module from the util package since the util package is not exposed (and we're not compiling with -package util)? Well it turns out that we had another package installed that depends on the util package (cabal-0.5 as it happens) and that package is exposed by default. It seems that this implicitly exposes the util package. This is the right behaviour, although I agree it's a little confusing. The util package has not been exposed as a result of being depended on by cabal-0.5, but GHC has correctly inferred that it is part of the program, and so its modules cannot clash with any others in the program. The documentation does describe this (section 4.8.1): There must be no overlaps in the modules provided by all of the exposed packages, and the packages they depend on, and so on. it doesn't mention the modules of the program though. Perhaps it should, I'm open to suggestions for better wording. It would be nice if the error message said something like util-1.0 is included because it is a dependency of I'm surprised that you could use -ignore-package util, I would have expected that to cause an error due to the dependency from cabal to util. That might be a bug - can you confirm? Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: exposed package exposes dependent packages
On Tue, 2005-04-05 at 23:34 +0100, Simon Marlow wrote: Well it turns out that we had another package installed that depends on the util package (cabal-0.5 as it happens) and that package is exposed by default. It seems that this implicitly exposes the util package. This is the right behaviour, although I agree it's a little confusing. The util package has not been exposed as a result of being depended on by cabal-0.5, but GHC has correctly inferred that it is part of the program, and so its modules cannot clash with any others in the program. But it's not part of the program. In our test program we do not import any module from the dummy package (which is the exposed package that depends on util). Our example was compiling happy. happy does not import anything from cabal-0.5 and yet it was hit by this problem. Unless we consider 'part of the program' to be all modules in all exposed packages (and all modules in 'efectively exposed' packages like util via the cabal-0.5 dep). If this is not a bug, the only thing we can do is make sure we never create an ebuild for anything that installs an exposed package that depends on one of the old hslibs packages. Otherwise several other unrelated programs will fail to build. The documentation does describe this (section 4.8.1): There must be no overlaps in the modules provided by all of the exposed packages, and the packages they depend on, and so on. it doesn't mention the modules of the program though. Perhaps it should, I'm open to suggestions for better wording. So is it all modules provided by exposed packages or all modules included (directly or indirectly) in the program? It would be nice if the error message said something like util-1.0 is included because it is a dependency of That would help. We were left wondering how on earth util was getting included into the program. I'm surprised that you could use -ignore-package util, I would have expected that to cause an error due to the dependency from cabal to util. That might be a bug - can you confirm? Yes indeed. Until recently we compiled happy with -ignore-package util to work around this issue. Our new solution is to declare cabal-0.5 to be incompatible with GHC 6.4. Duncan ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
