Roger Leigh <[email protected]> wrote: > On Mon, May 09, 2011 at 09:33:48AM +0200, Tollef Fog Heen 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 <a > href="http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken";>http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken</a> > is relevant in this context. > > These threads also contain issues pertaining to the / vs /usr split: <a > href="http://lists.debian.org/debian-devel/2009/05/msg00075.html";>http://lists.debian.org/debian-devel/2009/05/msg00075.html</a> > <a > href="http://lists.debian.org/debian-devel/2011/01/msg00006.html";>http://lists.debian.org/debian-devel/2011/01/msg00006.html</a> > > > But all of the existing issues identified by having the separation fail to > address an even bigger issue: sharing /usr is entirely incompatible with a > modern package manager, and this has always been the case. See: > > <a > href="http://lists.debian.org/debian-devel/2011/01/msg00152.html";>http://lists.debian.org/debian-devel/2011/01/msg00152.html</a> > > > In this message, I've detailed various historical use cases for a separate > /usr, together with brief pros/cons/rationale. On a modern Linux system, > most of these make zero sense, and it is preferable to have them on the same > filesystem. This summary is the most important point (refers to dpkg, but > applies to all package managers): > > "I think many instances of confusion and misunderstanding over the / and > /usr separation, particularly with regard to NFS mounts, but also covering > read-only mounts and recovery are due to not fully considering the > implications of a modern package manager on the traditional UNIX filesystem > hierarchy. We can consider that there are just two different types of > directory in the file system: > > • those managed by dpkg • those containing user data which are not under > dpkg control > > All locations managed by dpkg must be considered a unified whole; it does > not make any sense to share one part and not another. They must be updated > together or else the system will be left in a broken and inconsistent state. > A separate /usr is no longer required to boot the system now we have > initramfs." > > 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. > > This makes a lot of sense. > > From the FHS POV, I would like to suggest these changes: > > • "/usr is shareable, read-only data" > - Remove the "shareable" qualifier. With a package manager such as dpkg > or rpm etc., it does not make any sense to share /usr since the content is > managed as a whole with the other contents of /, including conffiles. > - While it's technically possible to share /usr, this requires a lot of > additional custom support scripts to sync the configuration files and > other parts of the software not provided under /usr; no distribution > caters for this use case directly. > - Even when you don't have a package manager, you still have the issue > with the configuration files not being shared (as pointed out elsewhere in > this thread). • Sharing / works, so permit sharing of / (which would include > /usr) > - Sharing a read-only / allows use on many hosts; host-specific > configuration can be stored in a writable aufs/unionfs overlay, or on /run > (for example). • Permit /usr to be a symlink to /. This gives distributors > the option of unifying the / and /usr namespaces. This is a logical > consequence of keeping / and /usr on the same filesystem. In the distant > future it might be possible to eliminate /usr entirely, but at this point > it would be appropriate to have the option of making it a symlink. > > Related to /usr it would also be good to: • Remove the special treatment for > /usr/X11R6; we no longer need it now X uses the standard hierarchy (same as > for /usr/games). >
I would like to have it the other way round. /usr is the distribution. / is the initramfs with the necessary bits to mount /usr _______________________________________________ fhs-discuss mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/fhs-discuss
