[fhs-discuss] static sharable files

Karl Goetz karl at kgoetz.id.au
Mon May 9 18:47:25 PDT 2011


On Mon, 9 May 2011 10:38:42 +0100
Roger Leigh <rleigh at codelibre.net> 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
> > http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
> > is relevant in this context.
> 
> These threads also contain issues pertaining to the / vs /usr split:
> http://lists.debian.org/debian-devel/2009/05/msg00075.html
> http://lists.debian.org/debian-devel/2011/01/msg00006.html
> 
> 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:
> 
> http://lists.debian.org/debian-devel/2011/01/msg00152.html

Thanks for the references. Re-reading the posts I realise i'd already
read them and it was good to be reminded about them.
Given these (4) links and related discussion I can't think of any
reason to keep /usr/ separate other then any issues embedded people
might have with them merged. If it won't cause issues for embedded dev
then I'd say we should merge /usr into / too.

> 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.

Sounds like a good step. would we note that /usr could/should be
deprecated, or would we simply save it for a future release of the FHS?

> 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).

This is [1] for Xfree (!) and [2] for games.

[1] http://bugs.linux-foundation.org/show_bug.cgi?id=73
[2] http://bugs.linux-foundation.org/show_bug.cgi?id=766
thanks,
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/20110510/dc5a0d0e/attachment.pgp 


More information about the fhs-discuss mailing list