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