"S. Alexander Jacobson"
The spec says that build-depends identifies the packages "needed to build this one."
If packages other than Ps may provide access to module B then the build-depends tag cannot identify the dependencies of module A because Ps are not necessary, only sufficient.
Build-depends identifies necessity not sufficiency.
If that's a big concern, it's easy to fix. I very much hope that the build-depends meaning will be expanded in the future to express more options. Build-depends in Cabal is inspired by Debian build-depends which have a richer syntax. For instance, you can say: Name: Foo Build-Depends: Bar | Bang, Baz I want Cabal to be able to do this some day. It just wasn't the kind of feature we wanted to focus on for Cabal 1.0. If you're very keen for this feature, patches are accepted as usual. It shouldn't be too hard. Tool support for Hackage would probably be a little harder, but not much. So here's what it would probably look like for Cabal: - Write test cases. Not as trivial as it might seem as first since there are a number of environmental issues to take into account. - Alter the Distribution.Version.Dependency type to allow a list of options. - At configure time, you check to see which of the dependencies are present. If none are present, then you can't continue, if more than one is present, then you need some way to choose: Prompt the user, allow configure flags, pick the first in the list, whatever. This will be simlar to how a version is chosen when the build-depends is a version range (already implemented). - Now after this, the rest of the build process is the same. - Write documentation :) For hackage / cabal-get you'd need to perform a similar check to see which packages are installed, and which you want to install before downloading and building the rest of the dependencies. This might make the dependency analysis harder, but not that much (winking at Lemmih). This would possibly cause us to run into the module overlap limitation more often. If it were actually much of a problem, it would probably show up in cases like this, particularly if Bar and Bang don't overlap 100% in their functionality and interface. For now, I'd honestly prefer to leave out optional dependencies until people are clammoring for them. They tend to show up in Debian in cases where two packages serve the same purpose, like mail transfer agents, database back-ends, or Haskell compilers. For the short-term, until Hackage is running smoothly for a little while, I think it's good to keep it simple.
5. Since more than one set of packages may contain the same set of modules, the current Haskell story cannot be consistent with the current Cabal story. Why can't multiple packages have the same set of modules?
Exactly!
Nothing prevents multiple packages from having the same set of modules. We simply can't compile them into a single program. As has been said (many) times already, this is a somewhat difficult engineering task, but not a fundamental limitation. peace, isaac