1 |
On Fri, Apr 08, 2016 at 03:20:24PM -0700, Daniel Campbell wrote: |
2 |
> Based on what I've read here in the thread, merging /bin and /sbin |
3 |
> into /usr/{sbin,bin} is a matter of convenience by putting most of the |
4 |
> static parts of a running system into a single path. As mentioned by |
5 |
> some people, however, that's not enough to make deployment across |
6 |
> multiple machines super simple. The distros that focus on that aren't |
7 |
> rolling release like we are, and thus don't face the same difficulties |
8 |
> that we do. In addition, Gentoo supports a broad number of choices for |
9 |
> users and some are advocating for an option. |
10 |
|
11 |
It is true that we offer a high degree of choice to users, but one of |
12 |
those choices is not which paths to install binaries and libraries |
13 |
into. |
14 |
|
15 |
We install some binaries/libraries in /{bin,sbin,lib*} and others in |
16 |
/usr/{bin,sbin,lib*}; the users don't get to choose which binaries and |
17 |
libraries go where. |
18 |
|
19 |
> At a higher level, I'm not really sure why we're discussing it. |
20 |
> Perhaps I missed it, but I didn't see an actual problem that someone |
21 |
> was having mentioned anywhere. The /usr merge seems to me as a partial |
22 |
> "solution" for a different type of environment; one that, arguably, is |
23 |
> better suited for a distro that's designed for such deployments. |
24 |
|
25 |
It would, for us, eliminate a lot of customization in the base-system |
26 |
ebuilds, for example, all of the rearrangement of binaries in coreutils, |
27 |
splitting of the binaries between / and /usr in procps, all calls to |
28 |
gen_usr_ldscript in any ebuilds, among other things. |
29 |
|
30 |
In short, it would make packaging simpler, and maintain backward |
31 |
compatibility at the same time since the symlinks in / would exist. |
32 |
|
33 |
> I personally think sharing /usr over a network and deploying it to |
34 |
> multiple machines could be a recipe for disaster. It seems like a |
35 |
> business case scenario that would involve multiple other system |
36 |
> changes. It sounds like a great case for adding another profile or |
37 |
> something rather than changing things tree-wide. Maybe it's a case for |
38 |
> making profiles more powerful and flexible. Regardless, I'd hate to |
39 |
> see choice diminished here for the sake of a single set of rather |
40 |
> narrow use-cases. |
41 |
|
42 |
Based on what I said above, I don't see what choice is being diminished |
43 |
by the /usr merge, since we do not give users a choice about how their |
44 |
file system is laid out, or where packages are installed. |
45 |
|
46 |
If I'm honestly missing something, enlighten me. :-) |
47 |
|
48 |
William |