Re: Package format/management ramblingss

[Alfred M. Szmidt]

       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.

I am not particularly fond of this, since this just adds unneeded
complexity in handling packages.  Isn't it simpler to keep all the
information about installed/uninstalled packages in one place, with
the actual package?

Also, your scheme--I think--makes it harder for us to implement the
package manager without having to write the translator for /package
right now, which my scheme doesn't, and without making quite large
changes later on which I was hoping we could avoid.  I also don't
particularly like the need to use translators when some other, more
efficient method would suffice; note that I ma not saying that my
method is more efficient.

Maybe you could elaborate on this if you have the time.


I might note that our schemes are very similar, they just differ on
this one point I think, and maybe that I had modified mine to be
easier to implement right now without the usage of translators.  The
scheme that I purposed was actually based on information that I
gathered from Wolfgang Jaehrling aeons ago.

   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.

One thing you didn't address how pre/post script should be handled;
scripts that have to be run during/after installation/deinstallation.

I guess that each package could have those special files in their
binary tar ball that would be run (manually, or by the package
manager).

   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.

One would have to record which files can be virtual concatenations in
the meta-data of the binary package.  Since not all files in /etc can
be concatenated into one virtual file.

I am thinking of how this would be handled for now, the only solution
I see is to write this translator (which Wolfgang would like to be
called `kitten') right now.  I might do this if nobody else does;
shouldn't be hard.

   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.

What will happen if one removes /disk1/installed/emacs-21.2, but not
the symlink?

   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.

This is a nice feature.  But what happens if foo:1.0 tries to get a
file from /etc/foo.conf, which has a syntax that foo:1.0 doesn't
support (say it was changed in foo-2.0, and foo-2.0 is the "default"
version)?  Hmm... Maybe on a read() we could check
/packages/foo-1.0/etc/foo.conf instead.

   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.

And of course, it should provide a node where one can check these
dependencies.



On a not so related note, has there been a response from Nick Moffitt
about assigning the copyright for (some version of) GAR to the FSF?


Happy hacking.