irrelevant package

Duncan Coutts duncan.coutts at
Wed Jun 15 08:49:08 EDT 2005

On Wed, 2005-06-15 at 13:15 +0100, Simon Marlow wrote:

> > But remember that any exposed dependent package of P effectively
> > exposes package P anyway. So it's not the case that you can install
> > an unexposed package and assume that it'll all be ok. Any package
> > installed later can come along and expose your package and you're
> > back to the problem that no programs/libs with your module M can now
> > be complied (without several -hide-package flags).
> A package is never exposed as a result of being depended on by another
> package, but its modules are brought into the module namespace.
> The difference is that you can import modules from an exposed package,
> you can't from a hidden package.  This is true even if the hidden
> package is depended on by another exposed package.

True it is not exposed, but it's being brought into the module
namespace. ("effectively expose" was not a good term for what I meant.)

The point is, it is the being brought into the module namespace that's
the problem. Using a flat module namespace in any library package P can
pollute the module namespace for all other programs (even if the library
is not exposed by default because any library package Q that uses P and
is exposed will bring package P's modules into the module namespace).
Then all those modules in package P will clash with modules of the same
name in your own program even if you never import anything (directly or
indirectly) from package P or Q.

As I've mentioned before, the canonical example of this problem is the
GetOpt module from the util package (part of the old hslibs collection
of packages which use flat module names). If you install any library
package (lets call it package "foo-0.1") that uses the util package and
is exposed then you can no longer use the module name "GetOpt" in any
other program you compile from then on, even if none of that program's
modules import any module from package "foo-0.1" or "util". That is, it
breaks totally unrelated programs, eg happy in this example.

I think the bug in this case is the fact that the modules are considered
to be part your program even though they are never imported (directly or
indirectly) or even any modules from the same package are imported (if
we take the reasonable assumption that if one module from a package
becomes part of your program's module namespace then all of them do).


More information about the Libraries mailing list