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

[Richard M. Stallman]

    By default, all packages that belong to the system live in /packages,
    and then /stow contains symbolic links to /packages/PACKAGE, from
    which unionfs builds /bin, /sbin, ..., etc.

I don't understand why you have both /packages and /stow.
Your design differs from the one I suggested.  In my design,
there was only /packages, and its role is like the role
of /stow in your design.  (Why call it "stow"?  That name
has no useful significance.)

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

    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?

    One could also store ld.so.1, unionfs, and all other core bits in
    /init (or similar), and just use those filenames.  But then when
    upgrading glibc/hurd/gnumach one must upgrade /init in some manner
    that doesn't involve unionfs, maybe copying the currently installed
    versions there on shutdown.

I don't see any problem in this.  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.

       I think that the better solution to that is create a group of
       packages that will not be managed by unionfs.

    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.  The usual package management system
could be used to bring in new versions of thee packages, but then, to really
make them take effect at boot, you would have to give a special command.

The special command would copy certain specific files from the places
where unionfs puts them into /boot, /hurd, or wherever.

    If a system does not allow debugging failed boots, or debugging after
    boot when complex software like package managers and union filesystems
    fail (as they certainly will), it seems unlikely to be successful.  Bugs
    (or misuses or ...) are inevitable; users need to have the tools
    necessary to figure out what is wrong and repair it.

I agree.

Here is another idea.  When unionfs is not running, /boot appears as
/bin and as /lib.  /boot would contain whatever executables you want
available for poking at a system which is not booting properly, as
well as the files required by GRUB.  /hurd could be a symlink to
/boot.  Then everything needed for booting would be there, and that
single update command would update everything.

You could update the contents of /boot the underlying directory as follows:

cd /boot
for file in *; do
  cp /bin/$file .
done

Here's another idea.  There could be a backup boot directory called
/boot-backup, and a way to boot the system so it would use
/boot-backup instead of /boot.  This way, you could update /boot,
reboot, and if it works well for a week, you could then copy /boot's
contents to /boot-backup.  This way you can be really safe.

There are many ways to rearrange the details of such a scheme.
I don't know all the details of GRUB.  Perhaps rearranging the details
would make it fit more conveniently with GRUB.