1 |
On Thu, Apr 07, 2016 at 11:12:13AM +0200, Alexis Ballier wrote: |
2 |
> On Wednesday, April 6, 2016 11:36:09 PM CEST, Richard Yao wrote: |
3 |
> > As for those benefits, they do little for {/usr,}/sbin vs |
4 |
> > {/usr,}/bin, which is where the incompatibilities tend to live. |
5 |
> > I encountered one of these in powertop the other day (patch |
6 |
> > pending). The benefits of being able to access things from both |
7 |
> > places are somewhat exaggerated given that compatibility among |
8 |
> > systems has long required searching $PATH and likely always |
9 |
> > will. |
10 |
> |
11 |
> PATH is a shell thing; some libc functions like execvp duplicate this |
12 |
> functionality but that's all; you dont have PATH in shebangs nor in execv. |
13 |
> |
14 |
> >> Note, we are not |
15 |
> >> talking about squashing /usr out of the equasion, but merging /bin, |
16 |
> >> /sbin and /lib* into their counterparts in /usr and creating symlinks in |
17 |
> >> the root directory pointing to the counterparts in /usr. |
18 |
> > |
19 |
> > While one guy did the reverse (and the reverse ought to be okay |
20 |
> > for those that want to do that), no one appears to think that |
21 |
> > adopting the reverse is what is being suggested. Having this |
22 |
> > sort of clarity on whether forcing this on everyone via |
23 |
> > baselayout update, just providing the option for those who want |
24 |
> > it or some combination of the two (e.g. a long transition period |
25 |
> > in which both are supported) is being discussed would be nice |
26 |
> > though. This is not a Boolean decision. |
27 |
> |
28 |
> I've been under the impression since the beginning of the thread that it is |
29 |
> what is being proposed: make it possible but support both. We can't force |
30 |
> usr-merge without battle testing the migration process anyway, which means |
31 |
> there needs to be such a long transition period. |
32 |
|
33 |
I do agree that we need a testing period to iron out the migration |
34 |
process. Like I said, I'm not quite comfortable even with running it |
35 |
here because I don't know if it will break my system, and once you do |
36 |
the migration, the only way to undo it is to wipe and re-install. I have |
37 |
thought about a way to roll back, but I don't see that as very feesable, |
38 |
so once you migrate to a /usr merged setup, there is no way to undo it. |
39 |
|
40 |
Also, the usr merge affects linux only; we aren't talking about |
41 |
messing with *bsd. |
42 |
|
43 |
After the testing period is over, I'm confused about why we should |
44 |
support both layouts. With separate usr without initramfs gone, the usr |
45 |
merge is transparent to end users because of the symbolic links in /, so |
46 |
there should be no reason to keep supporting both layouts once we are |
47 |
satisfied with the migration process. |
48 |
|
49 |
William |