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
/var.
> > 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
bits.
- Josh Triplett
Reply to: