[fhs-discuss] static sharable files
Tollef Fog Heen
tfheen at err.no
Mon May 9 00:33:48 PDT 2011
]] Bruce Dubbs
| 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.
I think
http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
is relevant in this context.
| 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'.
|
| Another option is yet another top level directory, but that is unappealing.
Another option is to deprecate or disallow /usr not being on the root
file system.
Separate /usr made sense back when drives were small and disk space was
expensive, but in the vast majority of cases today, having /usr on the
root file system is no real burden. Not having it on the root file
system means more brittle setups and trying to share /usr between
installations can easily lead to maintenance headaches.
Separate /usr makes sense is in the embedded case where you are
seriously space-restricted and you might want have your OS on fast flash
and the apps and user data on cheaper, but slower flash. In those
cases, I'd suggest putting apps in /opt rather than the more common
/usr.
Regards,
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
More information about the fhs-discuss
mailing list