[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Clarification about section 3.1 (The Root Filesystem, Purpose)
From: |
Marcus Brinkmann |
Subject: |
Re: Clarification about section 3.1 (The Root Filesystem, Purpose) |
Date: |
Mon, 14 Oct 2002 17:37:06 +0200 |
User-agent: |
Mutt/1.4i |
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/
- Re: Clarification about section 3.1 (The Root Filesystem, Purpose), Alfred M. Szmidt, 2002/10/12
- Re: Clarification about section 3.1 (The Root Filesystem, Purpose), Daniel Quinlan, 2002/10/12
- Re: Clarification about section 3.1 (The Root Filesystem, Purpose), Alfred M. Szmidt, 2002/10/12
- Re: Clarification about section 3.1 (The Root Filesystem, Purpose),
Marcus Brinkmann <=
- Re: Clarification about section 3.1 (The Root Filesystem, Purpose), Niels Möller, 2002/10/14
- Re: Clarification about section 3.1 (The Root Filesystem, Purpose), Thomas Bushnell, BSG, 2002/10/14
- Directories or Libraries ?, Thomas Sippel - Dau, 2002/10/15
- Re: Clarification about section 3.1 (The Root Filesystem, Purpose), Thomas Bushnell, BSG, 2002/10/14
Re: Clarification about section 3.1 (The Root Filesystem, Purpose), Marcus Brinkmann, 2002/10/12
Re: Clarification about section 3.1 (The Root Filesystem, Purpose), Richard Kreuter, 2002/10/12