On Fri, Apr 08, 2016 at 03:20:24PM -0700, Daniel Campbell wrote:
> Based on what I've read here in the thread, merging /bin and /sbin
> into /usr/{sbin,bin} is a matter of convenience by putting most of the
> static parts of a running system into a single path. As mentioned by
> some people, however, that's not enough to make deployment across
> multiple machines super simple. The distros that focus on that aren't
> rolling release like we are, and thus don't face the same difficulties
> that we do. In addition, Gentoo supports a broad number of choices for
> users and some are advocating for an option.
 
It is true that we offer a high degree of choice to users, but one of
those choices is not which paths to install binaries and libraries
into.

We install some binaries/libraries in /{bin,sbin,lib*} and others in
/usr/{bin,sbin,lib*}; the users don't get to choose which binaries and
libraries go where.

> At a higher level, I'm not really sure why we're discussing it.
> Perhaps I missed it, but I didn't see an actual problem that someone
> was having mentioned anywhere. The /usr merge seems to me as a partial
> "solution" for a different type of environment; one that, arguably, is
> better suited for a distro that's designed for such deployments.

It would, for us, eliminate a lot of customization in the base-system
ebuilds, for example, all of the rearrangement of binaries in coreutils,
splitting of the binaries between / and /usr in procps, all calls to
gen_usr_ldscript in any ebuilds, among other things.

In short, it would make packaging simpler, and maintain backward
compatibility at the same time since the symlinks in / would exist.

> I personally think sharing /usr over a network and deploying it to
> multiple machines could be a recipe for disaster. It seems like a
> business case scenario that would involve multiple other system
> changes. It sounds like a great case for adding another profile or
> something rather than changing things tree-wide. Maybe it's a case for
> making profiles more powerful and flexible. Regardless, I'd hate to
> see choice diminished here for the sake of a single set of rather
> narrow use-cases.

Based on what I said above, I don't see what choice is being diminished
by the /usr merge, since we do not give users a choice about how their
file system is laid out, or where packages are installed.

If I'm honestly missing something, enlighten me. :-)

William