"Alfred M. Szmidt" wrote:
>
> Daniel Quinlan <[EMAIL PROTECTED]> writes:
> > Alfred M Szmidt <[EMAIL PROTECTED]> 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
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
