1 |
On 09/29/2013 09:03 PM, Greg Woodbury wrote: |
2 |
> One of the most obvious things that broke booting with a seperate /usr |
3 |
> is not GNOMEs fault, but GRUB 2's fault. |
4 |
> |
5 |
> the move of /bin to /usr/bin (for things like cp,mv,ln,ls) came after |
6 |
> the breakage of /usr, but is symptomatic of some distros cavalier |
7 |
> attitudes to the problem. |
8 |
> |
9 |
> /usr/lib/udev..... |
10 |
> /usr/lib/systemd..... |
11 |
> |
12 |
> were both placed in /usr despite objections from a number of folks. |
13 |
> |
14 |
> So claims that udev and systemd are not responsible are not true. |
15 |
> |
16 |
> /usr/lib/e2initrd-helper was placed in /usr despite objections. |
17 |
> /usr/lib/libdevmapper* was moved despite objections... |
18 |
> /usr/lib/liblvm2* helpers were placed in /usr despite objections... |
19 |
> |
20 |
> There were deliberate placements of "new" or updated libraries in /usr |
21 |
> that were known ahead of time that would break the use of a separate |
22 |
> /usr filesystem. |
23 |
> |
24 |
> It was pointed out quite plainly at the time, and the placements were |
25 |
> made anyway, dismissing the concerns are "mere historical artifacts" or |
26 |
> "clinging to ancient and outmoded traditions." |
27 |
> |
28 |
> The *same things* are still being cited (about being outmoded) in |
29 |
> dismissing concers about forcing useres to adopt technologies they do |
30 |
> not want to use. |
31 |
> |
32 |
I agree with you but I think the distinction made on udev and systemd is |
33 |
that their *upstreams* didn't suggest they go in /usr. I don't know for |
34 |
sure since I don't follow systemd and frankly detest it, but if they |
35 |
said systemd and udev belong in /bin or somesuch, then they can't be |
36 |
held responsible. The responsibility for that decision falls on the |
37 |
maintainers, but it's compounded by the dependencies of systemd/udev. |
38 |
They depend on dbus, which resides in /usr. Was that an upstream |
39 |
decision or a distro decision? If we follow this dependency tree of /usr |
40 |
moves, which package was the first to migrate to /usr and begin this |
41 |
problem? The move to /usr was a social one that started years ago, not a |
42 |
technical decision made this year. The issue right now is damage control |
43 |
and, for some, maybe taking a good look at the FHS and deciding what |
44 |
really makes sense. |