Re: Package format/management ramblingss

[Richard Stallman]

    Each package might have a "disabled" and "enabled" bit that can be set
    (or unset), which will make the package available to the whole system.

There's no need for this.  In the Hurd-based design we should
ultimately used, you control whether a package is installed by making
or deleting a symlink to it from /packages.  There's no need for
any other way.


Here is my design for a package installation and deinstallation system
for GNU.  It makes use of the features of the Hurd to make
installation and deinstallation extremely easy.

We have a directory /packages that has a special meaning: every
subdirectory of /packages is an installed package.  Most often it
contains symlinks to directories, and they too are installed packages.

Directories such as /bin and /etc where packages can install files are
handled by special translators that act as virtual unions under the
control of /packages.  /bin is the virtual union of /packages/*/bin,
and /etc is the virtual union of /packages/*/etc.  Some files act as
virtual concatenations under the control of /packages.  Thus,
/etc/inetd.conf could be a virtual concatenation of
/packages/*/etc/inetd.conf.

You would normally unpack a package such as Emacs 21.2 under some
directory, let's say it is /disk1/installed.  So you create a
directory /disk1/installed/emacs-21.2.  It would have a subdirectory
/disk1/installed/emacs-21.2/bin containing files such as emacs, etags,
and emacsclient.

To install this package, you would make a symlink /packages/emacs ->
/disk1/installed/emacs-21.2.  (The name of the symlink is mostly
irrelevant.)  Instantly Emacs 21.2 would be installed.  The files in
/disk1/installed/emacs-21.2/bin would all appear in /bin.

Deinstallation is equally simple: just delete the symlink.  Note that
neither installation nor deinstallation involves any alteration,
copying or movement of the files that actually make up the package.

As an added feature, we can provide for renaming of executables.  If
the name of the symlink has a colon in it, the text after the colon is
appended to all file names in /bin.  So if you call the symlink
emacs:-21.2, /disk1/installed/emacs-21.2/bin/emacs would appear as
/bin/emacs-21.2.

Package relationships such as dependencies can be handled by this
mechanism too.  If a package is "installed" but its dependencies are
missing, /packages can detect that and not install it.  If there
are two executables with the same name, in different packages,
/packages could decide based on package priority relationships
which one to choose.