On Sun, May 08, 2011 at 07:51:49PM -0500, Bruce Dubbs wrote: > Currently the FHS has a discussion in Chapter 2 about sharable and > unsharable files that are static or dynamic.
> The example shows /usr as a prototypical static, shared directory. The > implication is that /usr can be mounted from a remote host. > The problem is that /usr has become a place that is necessary before a > network mount is available. For instance, if an administrator finds it > necessary to use lspci, or lsusb before the networked /usr is mounted, > the pci.ids and usb.ids files are not available. And why in the world should an administrator have to run either of these commands? If the admin wants to draft a mail and send it while waiting for /var to fsck, the lack of /var/spool will impede this as well, but I don't see how either has anything to do with the purpose of supporting a minimal root partition - namely, to ensure the availability of a minimal set of functionality that can be used to bootstrap and/or recover the rest of the filesystem. (FWIW, I'm aware that udev wants - or at least, wanted, in the recent past - to call helper tools that parse pci.ids and usb.ids for additional information, and that this can happen at any time before or after /usr has become available. However, given what I've seen of how this info is being used, as far as I'm concerned this is a layering violation on the part of those optional udev components, and another solution should be sought on the part of implementors that doesn't blatantly violate the FHS.) > Where then, should a program store auxiliary data files that may be > needed before any networking is configured? Candidates from the current > top level programs include /bin, /boot, /dev, /lib, /root, and /sbin. > None of these seems appropriate. > Perhaps a subdirectory hierarchy in /lib, say /lib/data/<package>/ may > be appropriate, but that goes against the current definition of /lib > that says: 'Essential shared libraries and kernel modules'. Correct, it does go against the current definition. It is, however, what is being done in practice, by analogy with /usr/lib - cf. /lib/modules, /lib/security, /lib/udev, /lib/firmware, /lib/init (upstart), /lib/systemd. Now that the FHS has awoken, I think it's a fine thing to standardize the use of per-application subdirectories under /lib. > I take no position on this topic right now, but want to present it for > discussion. Thanks for raising it! :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ [email protected] [email protected]
signature.asc
Description: Digital signature
_______________________________________________ fhs-discuss mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/fhs-discuss
