On Mon, Dec 24, 2012 at 4:43 PM, Mark David Dumlao <madum...@gmail.com> wrote: > On Tue, Dec 25, 2012 at 4:00 AM, Dale <rdalek1...@gmail.com> wrote: >> If I put / on LVM, I need a init thingy. > No you don't. You could use a boot partition. Or grub2.
I don't remember reading /boot as a suggested solution. Frankly, that's an interesting idea. And I'd completely forgotten about grub2. That actually sounds promising. > >> So, worked for ages, then it breaks when people change where they put >> things. Answer is, don't change where you put things. Then things >> still work for most everyone, including me. I'm not a programmer nor am >> I a rocket scientist but even I can see that. If I can see it, I have >> no idea why a programmer can't other than being willingly blinded. ;-) > > You have no idea why it's being deprecated because you STAUNCHLY > REFUSE TO READ why so, even when it's blatantly being spelled out over > and over again why it's being done that way. > > recap: many packages depending on udev keep putting stuff in their > udev rules that depend on binaries in /usr. It's not udev's > responsibility to fix or maintain these packages. Nobody ever argued that it was. The reason this argument is so heated on this list has its roots in an earlier discussion, going back about a year and a half ago. It started when systemd was brought up as a response to one problem or another a few times, and critiques and arguments against it were often met with what read like bad-faith arguments in dismissive tones. Elsewhere, systemd's architect met criticisms in a similarly dismissive fashion. This made some folks (myself included) wary of systemd and anything it controlled, simply because it seemed useless to try to participate in rational critique. Then udev announced it was going to merge into systemd's source tree for better developer interop. At that point, some of us feared (rightly, as it turned out) that the top-down, my-way-or-the-highway attitude from systemd would take over udev, and that the close proximity in the source tree would make it difficult for the udev component to exist independently and in a stable fashion. (Where 'in a stable fashion' means "doesn't become a moving target for anyone apart from systemd trying to interoperate with it.) I remember feeling like I'd just seen a train derail, and was watching a large, slow moving train wreck. Then came the declaration of "separate /usr is broken", much to the dismay of those of us for whom that configuration truly did work just fine. Yes, we understand that, in an overly complex system, dependencies can get mixed up and you need to resolve that somehow. (Personally, I think that any binary outside /usr that depends on binaries or data inside /usr is broken and should be fixed.) Then came the decision to move udev inside /usr, forcing the issue. Now, it'd been long understood that udev *itself* hadn't been broken. The explanation given as much as a year earlier was that udev couldn't control what *other* packages gave it for rules scripts. OK, that's not strictly udev's fault. That's the fault of packages being depended on at too early a stage in the boot process. And, perhaps, hotplug events for some devices _should_ be deferred until the proper resources for handling it are available. I can think of at least a few ways you could do that. And, yes, this was a problem systemd was facing, and wasn't finding a way out of. (Why? I still don't know. Maybe they didn't want to implement dependency declarations or demand that packages impement partial functionality to reduce initial dependencies.) Still, instead, the decision was made by the systemd/udev management to give udev the same _intrinsic_ dependency faults that systemd had, and udev, previously, hadn't. Previously, udev was a tool that you would use, and you would be expected to be wise while using it. Now, udev is a tool that's lost some of its power in order to force an environment more suitable for systemd. -- :wq
