[fhs-discuss] static sharable files

[Karl Goetz]

On Mon, 09 May 2011 09:33:48 +0200
Tollef Fog Heen <tfheen at err.no> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.linux-foundation.org/pipermail/fhs-discuss/attachments/20110509/43ef80a4/attachment-0001.pgp