On Wed, Jul 18, 2012 at 8:25 PM, Michael Mol <[email protected]> wrote: > On Wed, Jul 18, 2012 at 1:58 PM, Michał Górny <[email protected]> wrote: >> On Wed, 18 Jul 2012 18:40:12 +0100 >> Ciaran McCreesh <[email protected]> wrote: >> >>> On Wed, 18 Jul 2012 12:35:58 -0500 >>> Canek Peláez Valdés <[email protected]> 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 >
