Re: Bootup and package managment (and a small status report)

[Alfred M\. Szmidt]

   I don't understand why you have both /packages and /stow.  Your
   design differs from the one I suggested.

It doesn't, see below...

   (Why call it "stow"?  That name has no useful significance.)

When you create a symbolic link in /stow, the package gets stowed into
the system. The name comes from GNU stow, which does something similar
but where you have to run the `stow' program to get the same effect.
I think the name of /stow is quite suitable, /packages will only make
you think about packages that you have that aren't installed.

   There is no need for the directory which you call /packages,
   because packages can be unpacked anywhere.

But it is needed.  One needs to have some place to extract all the
files that are needed to make GNU boot, run, and be usable, and from
there create symbolic links to what I call /stow.  Having a
semi-standard place where the system administrator can extract
packages that he wishes to install on the system is very useful.

       The problem is that when one boots GNU (all the way from grub),
       one needs /boot/gnumach, /hurd/ext2fs.static, /hurd/exec,
       /lib/ld.so.1, etc.  These files are not avaiable[0] since
       unionfs hasn't been started, and it in turn needs the same
       things.

   /boot and /hurd should not be managed by unionfs.  Could all these
   files be moved to /boot or /hurd?

Why shouldn't /hurd be managed by unionfs?  Translators are installed
there, it isn't much different from /bin or /libexec.

/boot could be used, since a user tends to modify it in either case to
install new kernels, or just update the menu.lst file.  But then you
won't be able to handle gnumach cleanly using the package manager,
since part of gnumach also contains C headers, which might have
different API's for different kernels.

   These programs are not optional; there is no need for users to be
   able to turn them on and off, and if it requires some special magic
   to install new versions of them, it is ok.

Special magic tends to make things very complex over time.

       Then you loose the whole idea of a package manager.  For
       example, one won't be able to switch between glibc versions
       easily, or upgrade to a new version cleanly.

   I think that is an exaggeration.  Needing a special command to
   update a few fundamental packages would be no disaster.

I don't, having as few special cases as possible makes things far
easier to maintain.


Thanks for the suggestions, I'll try to figure something out that is
nice and clean.