[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: from / to /usr/: a summary

On Mon, Dec 26, 2011 at 05:23:56PM -0800, Steve Langasek wrote:
> On Sat, Dec 24, 2011 at 08:17:25PM -0800, Josh Triplett wrote:
> > Not quite.  Redhat and others want to make this change (moving binaries
> > and libraries from / into /usr) not just for ease of maintenance (though
> > that makes sense too) but for several rather interesting reasons.  It
> > would consolidate almost everything managed by the package manager under
> > /usr.
> That's not interesting at all.

Sorry you don't find it interesting.  Other people do.  In any case, I
primarily wanted to explain the rationale, which went beyond the
"upstream being difficult" repeated by others in the thread.

> > Configuration would live in /etc (with templates possibly provided by
> > packages, though more and more packages follow the "override files in /usr
> > with files in /etc" approach and ship no /etc configuration by default).
> That's the FHS and has nothing to do with moving things.

Well aware of that; just trying to fill in the full picture of how the
top-level directories would look after a move from / to /usr.  Also, the
FHS says nothing about the current approach of overriding files in /usr
with files in /etc, which allows packages to stop shipping configuration
files in /etc that just consist of the default settings.

> > /var includes bits that change, which should not normally include
> > package-managed bits.
> That's also in the FHS.

Again, well aware of that; just trying to fill in the full picture of
how the top-level directories would look after a move from / to /usr.
Also, nothing in the FHS states that packages shouldn't ship files in

> > This would make /usr easy to snapshot, easy to exclude from backups,
> > easy to share between systems, easy to mark read-only (mount --bind -o
> > ro /usr /usr) and various other fun possibilities.
> I don't think /bin, /sbin, and /lib are seriously blocking anyone from doing
> any of these things today.

/bin, /sbin, /lib, /lib32, /lib64, and package-managed files in /var and
/etc make these things significantly less convenient.  More to the
point, all of those directories (as well as /usr) exist as top-level
directories right next to /home, /tmp, /lost+found, /media, and others
which often require different treatment.  Right now, all of the
activities I mentioned require careful inclusion/exclusion rules: either
"include /, except exclude a pile of top-level directories" or "include
a pile of explicitly listed top-level directories".  Personally, I'd
find it rather convenient to have all of that consolidated in /usr.  So
would the upstreams of various packages, hence this thread.

> Indeed, people have consistently argued in this thread that /usr shared over
> NFS is not a useful thing to try to do these days, and there's nothing
> about adding /bin, /sbin, and /lib to /usr that changes these arguments.

People have consistently argued that sharing /usr makes no sense without
also sharing all the other package-managed bits that live outside /usr,
such as /bin, /sbin, /lib, /lib32, /lib64, and so on.  However,
consolidating all the package-managed bits in /usr would make it
entirely sensible to share /usr as a single consistent pile of packaged

- Josh Triplett

Reply to: