gnu-system-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Richard M. Stallman
Subject: Re: Bootup and package managment (and a small status report)
Date: Wed, 21 Sep 2005 02:43:26 -0400

       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.

Every package needs to be somewhere, but there does not need to be
a standard place to put them.  It would be ok to have a "default, usual"
place to put them.

The name `/stow' is not clear and should not be used.  In my design I
called this `/packages'.  Another good name would be `/installed'.

       /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.

There is no reason why we should use one directory for both translators 
and the Hurd executables.  /hurd should be used for one or the other.

We could keep the translators there and move the Hurd executable into
/boot.

We are trying to solve the problem of how booting should deal with the
union fs.  The easy solution is to arrange to boot without it and make
the system run without it.

If minor details--such as keeping some boot-time executables and
translators in the same directory--are obstacles to this, that's nothing.
We can just change those details.

      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.

There is no need for installation of mach or l4 to work through the
package manager.  However, I think we could make it do so in other
ways.  For instance, a program that runs during timesharing could find
the necessary executable file via unionfs and make a link to it from
the necessary name so that booting can find it.

       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.

The difficulty you are talking about is much less than the difficulty
involved in maintaining GNU/Linux systems today.  So let's not
overestimate its importance.  Making boot use unionfs will cause much
more maintenance trouble.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]