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

Re: possible mass-filing of bugs: many shared library packages contain binaries in usr/bin



On Wed, May 08, 2002 at 04:12:27PM +0200, Wichert Akkerman wrote:
> In other words, it does not work at the moment but should be soon?
> (reason I'm wondering is that Hurd have long proclaimed they would
> not use /usr since they had shadowfs, which always sounded a bit
> premature to me).

Thomas answer was to the point, but to elaborate on that: shadowfs is not
the answer to dropping /usr, but the answer to people who say: We want to
seperate files on a small / partition and on a larger /usr partition
(with having / only the essential files needed for booting).  shadowfs will
allow them to do just that (and much more of course).

Getting rid of /usr is really a no-brainer, except you have to retrain
how you think about filesystems (which you have to do anything if you want
to make good use of the Hurd).  Having /usr makes as much sense as a
separate X11R6, KDE or other tree.  However, the desire to split the
filesystem orthogonal to directories is a very valid one, and that's what
shadowfs is making possible.  On a side note, this might be used in a later
Hurd-specific packaging system that allows you to have each package unpack
in a seperate directory tree, and just set/remove symlinks to install
packages (eg, setting a /packages/foo-1.32 symlink makes
/packages/foo-1.32/bin visible under /bin).  Also note that this allows
users to customize the system by just having their own set of symlinks
(possible merged with the systems default) and chroot (or even boot, if
system programs are replaced/overlayed) to that.  This is not as much work
to implement as it sounds, but it is of lower priority than stability and
things like pthreads, of course.  [shadowfs itself has higher priority than
making advanced use of it as described].

Any of such filesystems tricks are not too hard once you get into the Hurd
design and interfaces.  For example, Roland hacked up a native fakeroot
implementation for Jeff's autobuilder to work with in a matter of hours,
which works much nicer than the fakeroot package in Debian GNU/Linux,
because it doesn't need to put itself between the user and the C library and
thus avoids all the hairy details you have to get right to make it work. 
Instead, it just glues itself between glibc and the real filesystem ;)
(another program glues itself between glibc and the real auth server,
providing a faked root identity, and a third program finally enables you to
use both to start a program with a root directory port to the fakeroot
filesystem.  All of these components provide useful features in their own
right, and a shell script with a single command line provides the same
feature as the fakeroot program under GNU/Linux).

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de


-- 
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: