Re: [gentoo-user] systemd installation location

[Daniel Campbell]

On 09/29/2013 09:05 PM, Mark David Dumlao wrote:
> On Mon, Sep 30, 2013 at 9:50 AM, Daniel Campbell <lists@××××××××.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.