Re: [gentoo-dev] Opinion against /usr merge

[Alec Warner]

On Wed, Jul 18, 2012 at 8:25 PM, Michael Mol <mikemol@×××××.com> wrote:
> On Wed, Jul 18, 2012 at 1:58 PM, Michał Górny <mgorny@g.o> wrote:
>> On Wed, 18 Jul 2012 18:40:12 +0100
>> Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote:
>>
>>> On Wed, 18 Jul 2012 12:35:58 -0500
>>> Canek Peláez Valdés <caneko@×××××.com> wrote:
>>> > All the arguments for keeping /bin, /sbin, /usr/bin, and /usr/sbin
>>> > separated are really instances of the Chewbacca defense [1]. They
>>> > just don't make any sense.
>>>
>>> All the arguments for changing things are just realising that the
>>> horse has fled the barn and then trying to rationalise not needing a
>>> horse.
>>
>> I believe I don't need a horse. I don't even have a barn either.
>
> To carry the analogy, udev forcing a /usr merge is much like "We don't
> need a horse, so we don't think anyone else should have one, either.
> If they need a horse, they can use one of those newfangled tractors."
>
> Personally, I think the original reasoning behind udev's move was
> flawed. When I read it, it sounded like "we can't control whether or
> not anyone else puts boot-required packages into /usr before /usr has
> been mounted. In order to cover for those packages, we'll force the
> issue by putting ourselves there."
>
> I think that any package which puts boot-required things into a path
> which may not be available at boot time is inherently broken, and
> needs to be fixed. There's absolutely nothing about the move which
> both accounts for boot-required packages requiring access to /var
> _and_ a sysadmin's need to have /var as a special mount point.
>
> To me, it looks a lot like what once was / is now expected to be an
> initramfs, which I find extraordinarily problematic, for the following
> reasons:
>
> 1) There are no truly mature tools for automatically generating and
> installing an initramfs based on system requirements. Canek likes to
> recommend dracut, which still isn't marked stable. I've gotten stable
> genkernel to work reasonably, but its error reporting is terrible.
> 2) There's no good means for applying software and security updates to
> an initramfs. If having an initramfs is to be considered the new
> normal, there should be some means of updating it as part of routine
> system updates.

Debian uses initramfs-tools...

> 3) With an initramfs and the tools to generate it, we have more moving
> parts were previously there were few.
>
> --
> :wq
>