The module system should ideally be built with some thought of how the
external packages will be maintained.  We surely want to have stable
packages around, but there is no such thing as a "stable package"
sitting by itself.  A package can only be stable with respect to a set
of other packages that it might be loaded along with.  Thus, we will
want to have repositories, and repositories will work best if the
package format has predicted their needs.

One particular issue to think about is how dependencies work.  They
should:

	1. Exist.  Without dependencies, loading packages from a repository
requires requires a lot of manual work.

	2. Refer to a large enough number of packages, that new package
versions can be posted without requiring a cascade of other updates to
be posted.  Without this property, images can get stuck in a gridlock,
unable to upgrade anything.

	3. Refer to a specific enough set of packages, that any one of them is
likely to work.  That is, the dependencies should be tight enough to be
meaningful.

	4. Not require loading too many entire packages, in order to figure out
the dependencies.  For example, automatic dependencies based on loading
the packages to see that classes they refer to, make it tricky for a
repository browser to know what the dependencies are -- because it
hasn't loaded the packages yet.

#3 does not seem to be an issue in practice, despite a lot of talk it
gets.  It is easy to get some tolerable level of reliability (e.g., you
don't load a WWW browser without an HTML parser), and it similarly seems
impractical to get really solid reliances (this HTML parser will
definitely work).  The achievable area in the middle is large and almost
impossible to miss.

The other items, to contrast, take some care.

As an existence proof, Debian has shown that simple name-based
dependencies are enough to meet all four requirements.  So all we really
need are dependencies like "depends on some package named Network-HTML".
 If someone has a better idea, that is fine too, but note that there is
at least one solution here.


Finally, the related works section should include Debian's module
system.  The mechanics of loading and unloading such packages are
completely different from what we need, but some of their extra
information should map over.  In particular, they have worked out:
dependencies, install/uninstall code, and configuration.  Additionally,
they have an organization similar to our own, with hundreds of
independent developers scattered around the world.


-Lex