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