
Systemd eats udev, poettering says breaking not their problem - dogecoinbase
https://github.com/systemd/systemd/pull/2500#issuecomment-178071901
======
shakna
From a related issue [0]:

> We would switch over to sg3_utils when it is able to replace the udev tools,
> and remove the udev tools. It is just that someone who understands these
> devices needs to do the work. None of the systemd maintainers can do that.

I find it sensible that systemd wants to not maintain things they don't have
the experience to handle. That is great.

But answering a perfectly valid prompts like [1]:

> @poettering I get that. The current situation is unsustainable. And we will
> talk to our storage guys to find some solution. But meantime, we need some
> synchronization between downstreams. Otherwise everyone will implement a
> different naming scheme with downstream patches.

With [2]:

> Someone with knowlegde in that area should move them to a separate package
> that can be maintained outside of systemd/udev. Hannes worked on moving
> parts of scsi_id to sg3_utils, finishing that would be the first step I
> assume.

> Closing this pull request, for the above mentioned reasons.

There is a problem with systemd right now. The right move is to move it into
an external library, and work is under way for that.

In the meantime however, and it may be a very long meantime, systemd has some
serious compatibility problems with udev, which can have some really serious
side-effects.

A middle-point is needed.

People working with RHEL seem willing to help, but systemd won't take any of
it on board. It's not their problem.

I don't find that comfortable.

[0]
[https://github.com/systemd/systemd/pull/2363#issuecomment-17...](https://github.com/systemd/systemd/pull/2363#issuecomment-173274244)

[1]
[https://github.com/systemd/systemd/pull/2500#issuecomment-17...](https://github.com/systemd/systemd/pull/2500#issuecomment-179232623)

[2]
[https://github.com/systemd/systemd/pull/2665#issuecomment-18...](https://github.com/systemd/systemd/pull/2665#issuecomment-186199450)

------
aftbit
Can anyone summarize what the debate is about here? I feel like I'm reading a
very tiny slice of a larger debate. Is this just another example of systemd
aggressively dropping legacy support, or is there more going on here?

~~~
digi_owl
Udev existed for nearly a decade on its own before it was merged with systemd.
And upon that merger, Sievers, the then maintainer of udev and a close buddy
of Poettering, promised that udev would still be usable without systemd.

But since then every time the topic comes up, the systemd devs (Poettering and
Sievers in particular) as gone back on that promise.

------
Shalhoub
According to my limited understanding, some time back Poettering called for
udev to be subsumed into systemd. When systemd.udev breaks something his
response is. It shouldn't be in udev in the first place, it isn't my problem,
we lack the skills to make it work. Going on Poetterings past utterances in
response to criticisms of systemd, I have to say I am not impressed. It
demonstrates an arrogance, immaturity and lack of people skills. Perhaps
someone else should take over the helm.

