1 |
On 09/29/2013 08:40 PM, Mark David Dumlao wrote: |
2 |
> On Mon, Sep 30, 2013 at 8:54 AM, Daniel Campbell <lists@××××××××.us> wrote: |
3 |
>> I'm not affected by anything regarding the /usr switch, but I'd like |
4 |
>> to have a good talk with the first person who decided a |
5 |
>> system-critical binary belonged in /usr instead of /bin or /sbin. |
6 |
>> They've created a mess for every distro and any project that depends |
7 |
>> on their work. |
8 |
> |
9 |
> (sorry for the previous post, accidentally clicked somewhere onscreen) |
10 |
> |
11 |
> As I've pointed out before: |
12 |
> 1) "system-critical" is actually dependent on the system. A system dependent |
13 |
> on an smb share will find smbmount system critical. One dependent on |
14 |
> zfs-fuse will find fuse system critical. With the advent of fuse, |
15 |
> some filesystem |
16 |
> that depends on an arbitrary user program will find that system-critical. |
17 |
> While this works for for 99.(99?)% of user systems out there, FHS |
18 |
> is supposed |
19 |
> to be targetting all of them, and so it fails in principle in that respect. |
20 |
> I remember making a lengthy thread on this mailing list challenging how FHS |
21 |
> defined this and it appeared that nobody could make a defense. |
22 |
> 2) the reality is, it's not just binaries even. There are some things |
23 |
> that binaries |
24 |
> depend on, that in theory should be in /. For example, the hwid database, or |
25 |
> libraries. Libraries make for a complex problem, because /usr is supposed to |
26 |
> be network-sharable. Any libraries your programs depend on can't simply just |
27 |
> be pushed to /, because then there'd be the chance that the |
28 |
> programs and their |
29 |
> libraries were not in sync. |
30 |
Libraries were one of my concerns when I was replying. I thought to |
31 |
myself, "Well damn, won't shared libraries make this even more |
32 |
difficult?" Perhaps it's a case for static-linked core binaries. :) |
33 |
|
34 |
Anyway, I'm not in favor of FHS _per se_, but it sounds pretty |
35 |
reasonable to have some semblance of order among where different parts |
36 |
of a system go. Shoving everything into /usr and symlinking everything |
37 |
else seems like a stop-gap or good-enough solution that came about due |
38 |
to ignoring the existing standard (FHS) and refusing to try to change |
39 |
it. I could be wrong, though. My point is I'm not dogmatic about it; I |
40 |
just think that if the FOSS community were willing, a better solution |
41 |
could be crafted. |
42 |
> |
43 |
> I made a handful of criticisms to FHS in that thread before, and nobody was |
44 |
> able to mount a suitable defense. The point being, even in principle, separating |
45 |
> / and /usr is flaky design at best. That we just so happened to |
46 |
> accumulate a number |
47 |
> of packages that are historically installed to /usr is a consequence |
48 |
> of that. It's not |
49 |
> even necessarily the fault of the upstream developer, who's not |
50 |
> supposed to care so |
51 |
> much which PREFIX they install to, or the distro packager, who can't yet predict |
52 |
> how the user will tailor their system. |
53 |
> |
54 |
> If you were in the shoes of the ebuild packagers, you would be hard-pressed to |
55 |
> predict which packages belong in the / PREFIX and which ones in /usr PREFIX, |
56 |
> 100 times out of 100. But you need 100 times out of 100 or you'll get |
57 |
> people whining |
58 |
> that they can't boot or whining that they need to do some migration. That's |
59 |
> why / and /usr separation is broken. |
60 |
> |
61 |
I agree, but perhaps the / and /usr separation is a symptom of a greater |
62 |
problem instead of being the problem in and of itself. Like Inception, |
63 |
maybe we need to go further. :P |