On Mon, 09 May 2011 09:33:48 +0200 Tollef Fog Heen <[email protected]> wrote:
> ]] 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. While I'd be in favour of saying it should/must be available, i dont know if i'd agree we should require it to be on the / partition. ( I should probably do some more research on that). > 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. Anyone on the list who does embedded stuff who can comment? On my desktop, 4.5gb of the 4.7GB used on / (/var/ and /tmp are separate) is /usr. How does this ratio compare on embedded systems? > 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. for a repackaging vendor i can imagine /opt/ being the right place, but using /opt for OS components seems slightly bizarre to me (perhaps I'm just too used to the current fhs!). kk -- Karl Goetz, (Kamping_Kaiser / VK5FOSS) Debian contributor / gNewSense Maintainer http://www.kgoetz.id.au No, I won't join your social networking group
signature.asc
Description: PGP signature
_______________________________________________ fhs-discuss mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/fhs-discuss
