Thomas Sippel - Dau <[EMAIL PROTECTED]> 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 _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
