[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Clarification about section 3.1 (The Root Filesystem, Purpose)
From: |
Alfred M. Szmidt |
Subject: |
Re: Clarification about section 3.1 (The Root Filesystem, Purpose) |
Date: |
14 Oct 2002 17:25:28 +0200 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 |
Thomas Sippel - Dau <t.sippel-dau@ic.ac.uk> writes:
> "Alfred M. Szmidt" wrote:
>
> So, without flaming, what exactly is /libexec useful for ? I guess
> it is for objects that:
That should be /usr/libexec on *nix systems, GNU/Hurd has a symlink
from /usr to /. My mistake for not mentioning this.
[...snip...]
> Alfred, an you add anything compelling - so far it looks to me very
> much like /lib.
Well, consider the following scenario, /usr/lib is on a separate
partition and has been mounted in such a way that you cannot run any
executables in there. Where would you store these executables if you
do not want them to be in the PATH?
> Could the Hurd project live with the stipulation that /libexec ->
> lib is a valid implementation (as well as /usr/libexec -> lib), 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:
Not to start a flame wat here either, but what is the point of saving a single
inode?
[...snip...]
> Also, should libexec have suffixes like libia64 etc. ? Would those
> be libia64exec or libexecv9 ?
I would think that /libexec-<suffix> would be the most logical.
> Could the packages declare themselves as running in the "exec"
> architecture variant only, in which case /libexec is already valid
> according to the recent editions of FHS (contrary to Dan's immediate
> brushoff ?)
How would you define this exec architecture?
> > 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.
As noted above, /usr is a link to / on GNU/Hurd, and the plan is to
use a shadowfs/unionfs to solve the problem of "filling up /" (this is
not the only problem they solve, but this is one of them).
I see that I made an grave mistake of saying /libexec instead of
/usr/libexec, maybe it would be fine to add a /usr/libexec directory
instead of /libexec? And then adding /servers and /hurd to the
GNU/Hurd specific annex?
Cheer
--
Alfred M. Szmidt
- 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, 2002/10/14
- 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