All, In the initial discussions on a common architecture for building applications and libraries one of the goals was to reduce or eliminate untracked dependencies. The aim being that you could reliably deploy a package from one machine to another. We settled on a fairly traditional model, where one specifies the names and versions of packages of Haskell code. An obvious alternative model is embodied in ghc --make and in autoconf style systems where you look in the environment not for packages but rather for specific modules or functions. Both models have passionate advocates. There are of course advantages and disadvantages to each. Both models seem to get implemented as reactions having the other model inflicted on the author. For example the current Cabal model of package names and versions was a reaction to the perceived problem of untracked dependencies with the ghc --make system. One could see implementations such as searchpath and franchise as reactions in the opposite direction. The advantages and disadvantages of specifying dependencies on module names vs package names and versions are mostly inverses. Module name clashes between packages are problematic with one system and not a problem with the other. Moving modules between packages is not a problem for one system and a massive pain for the other. The fact is that both module name and package name + version are being used as proxies to represent some vague combination of required Haskell interface and implementation thereof. Sometimes people intend only to specify an interface and sometimes people really want to specify (partial) semantics (eg to require a version of something including some bug fix / semantic change). In this situation the package version is being used to specify an implementation as a proxy for semantics. Neither are very good ways of identifying an interface or implementation/semantics. Modules do move from one package to another without fundamentally changing. Modules do change interface and semantics without changing name. There is no guarantee about the relationship between a package's version and its interface or semantics though there are some conventions. Another view would be to try and identify the requirements about dependent code more accurately. For example to view modules as functors and look at what interface they require of the modules they import. Then we can say that they depend on any module that provides a superset of that interface. It doesn't help with semantics of course. Dependencies like these are not so compact and easy to write down. I don't have any point here exactly, except that there is no obvious solution. I guess I'd like to provoke a bit of a discussion on this, though hopefully not just rehashing known issues. In particular if people have any ideas about how we could improve either model to address their weak points then that'd be well worth discussing. For example the package versioning policy attempts to tighten the relationship between a package version and changes in its interface and semantics. It still does not help at all with modules moving between packages. Duncan