bug-hurd
[Top][All Lists]
Advanced

[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




reply via email to

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