Last updated at 4:12 am UTC on 29 March 2005
Reported by Lex Spoon
What problem is being addressed
- Easy installation of a large number of packages with a reasonably likelihood that they will Just Work.
- Development of occasional stable releases, where every package in the release has no known, highly serious bugs.
How it solves the problem
There are "branches" in the central repository. A branch sets a context just like a package universe: it specifies what packages are available for download, and how widely a package update is spread.
For coherence I think the author should write the sections above this line.
People can add what they want to these later sections, and can suggest that the author change the rest.
What's cool about it
There are several things we can copy:
- They have thought carefully about their dependency system, and have the following kinds of dependencies marked:
- depends: a package that is absolutely required before the present one can be loaded
- conflicts: a package that absolutely cannot be loaded at the same time as this one
- reccomends/suggests: a package that you probably want to load, for varying degrees of "probably".
- provides: not exactly a dependency. This specifies that the package provides some generic "virtual" package. For example, both "xemacs" and "gnuemacs" can provide "emacs". Other packages can then depend on the virtual package ("emacs") if they don't care which alternative package supplies their need.
- In general, they have a rich dependency language, but it doesn't seem to get used much. They allow restricting the versions of dependencies that are used, and they allow specifying alternatives in the dependency lists.
- They have a refined repository system (called APT), including management of mirrors, and having local non-public add-ons to a repository.
- They have carefully considered what load and unload scripts should be available. (Someone should dig up a link describing this...). They have: preinst, postinst, prerm, and postrm.
- They have thought about how to configure packages. Their decision is that the "postinst" script should also handle configuration, and that that same script can be re-executed later on if the user wants to re-execute a package.
- Configuration tools are being worked on by a few projects, so that you can configure a package no matter what kind of UI (X11, gnome, kde, console, line printer, ...) you are using.
It's very Unixy. The specific loading and unloading mechanisms do not apply directly.
The tools for repository management are terrible. The architecture seems to support local repository management (like the repository holding the Debian packages of Squeak!), but the tool support is lousy. I don't know if there is any fundamental reason for this; I think it is just not supported well.
Back to New Modules