Re: A proposed Roadmap

[Alfred M. Szmidt]

       I for one have very little idea of what the GNU system is
       intended to look like, not with respect to kernel hacking or
       super-advanced features or driver implementations, but simply
       from a basic user and/or sysadmin perspective.

   From a basic user perspective, it would look pretty much the same
   as GNU/Linux, I suppose.  I would not expect replacing the kernel
   to alter the user experience.

Then what is the difference between GNU and GNU/Linux?  If replacing
the kernel is (almost) not noticible for the user, why does it matter
that we use the Hurd, Linux, the BSD kernel or even the Solaris
kernel?

   As regards the sysadmin, I wrote down and posted here an idea for
   simple and clean package installation.  Does anyone have a copy to
   hand, to send it again?

It should be available in the mailing list archives.  I think this is
the mail you are refering to:

http://lists.gnu.org/archive/html/gnu-system-discuss/2004-05/msg00028.html

Here it is inlined:

From: Richard Stallman
Subject: Re: Package format/management ramblingss
Date: Tue, 11 May 2004 03:04:00 -0400

    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.