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

[Thomas Sippel - Dau]

"Alfred M. Szmidt" wrote:
> 
> Daniel Quinlan <quinlan@pathname.com> writes:
> > Alfred M Szmidt <ams@kemisten.nu> writes:
> >
> > > This is sad news.  As the /libexec proposal has been thrown out on
> > > several occasions I doubt that it will be accepted in the future.
> > > Also if a new system wants to introduce a new top level directory then
> > > you will need to add an specific annex for each system.
> >
> > Well, it is not really a useful directory.  I think most of the
> > proposals come because GNU software continually wants to use it even
> > though libexec violates FHS and most Linux distributions use FHS.
> 
> It is very useful actually.  I won't bother flaming up this topic once
> again, but if you want then I can point you to a nice and long thread
> about this topic on debian-hurd. :)

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)

    o  are not meant to be user-visible commands

    o  are not configuration (/etc)

    o  are not shared between architectures (otherwise /usr/share -
       /share was never mentioned afaicr)

    o  are not formally static libraries (/lib) or shared objects (/lib)
       The conceptual difference between a directory and a library
       escapes me, essentially, libraries are more efficient to read
       than directories, and more difficult to write, which makes them have 
       more homogeneous contents. In fact, the ar processor for libraries
       was also used as a convenient way to pack directory hierarchies
       into a single object.

Alfred, an you add anything compelling - so far it looks to me very much 
like /lib. 

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:

carrion# ls -li /usr/a/libexec/libdp* /usr/libexec/libdp* /usr/libexec /usr/a
6485206 -rw-------    1 root     sys            0 Oct 14 15:04 
/usr/a/libexec/libdpsx
1310033 lrwx------    2 root     sys            3 Oct 14 15:02 /usr/libexec -> 
lib
2097511 -r--r--r--    1 root     sys        96592 Oct 22  2001 
/usr/libexec/libdplace.so
2138845 -r--r--r--    1 root     sys        49184 Oct 22  2001 
/usr/libexec/libdprof.so
2284949 -r--r--r--    1 root     sys       619040 Oct 22  2001 
/usr/libexec/libdps.so

/usr/a:
total 0
6485205 drwx------    2 root     sys           25 Oct 14 15:04 lib
1310033 lrwx------    2 root     sys            3 Oct 14 15:02 libexec -> lib

Notice the inode numbers on the symlinks (!), I created /usr/a/lib/libdpsx
with touch, as my machine actually has /usr/as a filesystem and thus no
shared hard links for /libexec and /usr/libexec

Also, should libexec have suffixes like libia64 etc. ? Would those be
libia64exec or libexecv9 ?

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 ?)

> 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.

                                Thomas

*   Why not use metric units and get it right first time, every time ?
*
*   email: cmaae47 @ imperial.ac.uk
*   voice: +4420-7594-6912 (day)
*   fax:   +4420-7594-6958
*   snail: Thomas Sippel - Dau
*          Linux Services Manager
*          Unix Support Group
*          Information and Communication Technologies
*          Imperial College of Science, Technology and Medicine
*          Exhibition Road
*          Kensington SW7 2BX
*          Great Britain