Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Michael Mol]

On Mon, Dec 24, 2012 at 4:43 PM, Mark David Dumlao <madumlao@×××××.com> wrote:
> On Tue, Dec 25, 2012 at 4:00 AM, Dale <rdalek1967@×××××.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