Re: Clarification about section 3.1 (The Root Filesystem, Purpose)

[Marcus Brinkmann]

On Mon, Oct 14, 2002 at 03:24:50PM +0100, Thomas Sippel - Dau wrote:
> So, without flaming, what exactly is /libexec useful for ? I guess it 
> is for objects that:
> 
>     o  need to be available at boot time (otherwise /usr/lib)

The GNU/Hurd does not differentiate between /foo and /usr/foo, /usr is just
a symlink to .

>     o  are not meant to be user-visible commands

Correct.  /libexec has executables that should not be in the path of normal
or privileged users and that are not Hurd specific "translators" (another
special type of executables).
 
> Alfred, an you add anything compelling - so far it looks to me very much 
> like /lib. 

It's just as wrong to stuff it in /lib as it was for shared data (which is
now in /share).
 
> Could the Hurd project live with the stipulation that /libexec -> lib
> is a valid implementation (as well as /usr/libexec -> lib),

Probably, but what's the point?  The executables are not libraries.

> the way we 
> do for /lib -> usr/lib and /bin -> usr/bin? I tried that on an IRIX machine 
> and could even make the two links for /libexec and /usr/libexec hard 
> linked to each other, saving yet another i-node:

I hope that the point is not saving inodes.

> > I would think that it would be harder to have no standard at all, but
> > having an standard that lets the distribution extend itself is the
> > best choice.  Letting an distribution create root level directories
> > still achieves the goal of being similar between different systems.
> 
> The BIG problem with additional directories in / is that they need planning 
> for
> at every installation or upgrade, and will invariably trip up administrators
> when the root disk fills up because somebody has wanted an additional
> entry and starts stuffing data into it.

The GNU/Hurd will have different, more flexible ways to split up the data
among several storage devices (unionfs).  For non-GNU systems, we could talk
about /usr/libexec in addition to /libexec.  We shortcut that anyway.

It's just that we are used to simply drop /usr in all communication.  But it
is feasible to add /usr/libexec for other systems.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus@gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/