On 09/29/2013 09:05 PM, Mark David Dumlao wrote: > On Mon, Sep 30, 2013 at 9:50 AM, Daniel Campbell <li...@sporkbox.us> wrote: >> 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. > > It's true that it's nice to have a semblance of order where different parts > go. > But "all libraries and binaries in /usr" is also a semblance of order. You > don't > separate stuff for the sake of separating stuff. You separate them because you > have a good reason to separate them. It turns out that there isn't a good > reason > to separate them, and that there's no way to predictably separate them. > > Mushing them together isn't just a stop-gap or good-enough solution. The > idea of keeping system-critical separate from non-critical was not > maintainable > in the long run to begin with. > If separating them was unmaintainable, why bother with /bin and /sbin at all, then? If /usr is essentially replacing what / was originally, it's hard to take any filesystem standard seriously and we return to chaos. What was /usr's original purpose? I'm not really in favor of the separation or the merging; I'm in favor of what makes sense. For now, shoving things into /usr is practical because most other software does it. But that's following a trend. It's become *de facto* standard instead of a well-designed, well-reasoned standard. If the change to /usr was brought about because the FHS has holes in it, why not draft a new FHS completely from the ground up? Sometimes a vast rewrite is necessary in a standard, and the new standard could address modern challenges.
>>> 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 > > The greater problem is what I'm pointing out already. Even in principle, you > just can't predict which files belong in /. It's always been a case-by-case, > system-by-system thing, and it just so happens that 99.9xxx% of the cases > are the same. Distro packagers, however, have to decide for 100% of the cases. > So they're going to end up making weird decisions that are easy for you to > second-guess but are actually tough. > > If you want to solve the "hard problem", you want to create a tool that > will automate / and /usr migrations. Portage has to be aware of the tool > and maybe 100% of ebuilds will have to be rewritten to take advantage of the > dynamic prefixes set by the tool. That solves it for good, and you can have > your / and /usr separate. But only for gentoo. > > Every package manager needs to have a similar tool and similar intelligence > for that to work. > I agree, but I don't see a tool like that coming up. Enforcing a /usr merge and in edge cases forcing initramfs is the right *practical* solution, but I don't think it solves the greater problem, which is social and organizational. It may not even be a solvable problem, given how vast and diverse the FOSS world is. But maybe discussion on it can still be insightful, even if it can't be fruitful.
