Re: [gentoo-dev] last rites: sys-fs/eudev

["Eddie Chapman" <eddie@ehuk.net>]

Matt Turner wrote:
> On Tue, Sep 12, 2023 at 5:23 PM Eddie Chapman <eddie@ehuk.net> wrote:
>
>> Why would you think that by having an alternative in tree it means that
>> everyone else is then forced into doing work that they don't want to
>> and it will inconvenience everyone?
>
> Because it's already happened!
>
> commit 6404b064d63d182da4a8a193533a188cdf832d41 Author: Mike Gilbert
> <floppym@gentoo.org>
> Date:   Sun Jul 30 14:07:47 2023 -0400
>
> virtual/libudev: add eudev and sticky-tags USE flags
>
> eudev lacks API support for the new libudev functions that differentiate
> between sticky and current tags on device events.
>
> Add a USE flag so we can depend on the new API from libgudev.
>
> commit 319b4ed88674af738bd3fd90e56dc06c88de15db Author: Mike Gilbert
> <floppym@gentoo.org>
> Date:   Sun Jul 30 14:10:44 2023 -0400
>
> dev-libs/libgudev: depend on virtual/libudev[sticky-tags]
>
> And as a result we have had at least three bug reports from users
> complaining that they cannot update:
>
> https://bugs.gentoo.org/913702
> https://bugs.gentoo.org/913900
> https://bugs.gentoo.org/913954

If I'm not mistaken these 3 bug reports are all from users trying to run
their systems free of systemd, i.e. with eudev. So it is the eudev users,
not the udev (presumably the majority) ones who have been inconvenienced.

But I think I see your point that here eudev is causing problems for
Gentoo devs who are seeing perhaps an influx of users complaining because
of the problem created by eudev not keeping up with udev API changes.

However, perhaps a better approach might have been a news item informing
users of dev-libs/libgudev i.e. desktop users that using eudev with
dev-libs/libgudev is no longer going to be possible going forward (which
is out of control of Gentoo) and that they had a choice of either
uninstalling their desktop environment (if it depended on
dev-libs/libgudev) or switching to udev.  Then people who just run servers
can continue using eudev if they wish, and there would be no need to
remove it completely from the tree.  This is the approach I have argued
for earlier in this thread.

>> What if someone came along now and said
>> they were willing to "step up" and maintain eudev and they were suitably
>>  qualified? Is that really going to force everyone else to modify their
>>  ways?

> It doesn't matter what people say. It matters what they do. And so far
> no one has done anything in more than two years to make eudev worth
> keeping.

Yes I agree that actions matter not words. However, maintainership does
have to start with at least some words such as "OK I will step up and take
care of it"

> But the core of the issue for me is -- how is eudev even the slightest
> bit better in any way than systemd-utils[udev]?

Ok granted, as of right now eudev has not added any value as it has simply
forked, made some small changes but essentially does the same job. 
However, again you're missing the point, there is a very significant
number of users who for subjective/political/whatever non-technical
reasons want eudev instead of udev. These are valid reasons, and before
you try and argue they are not examine your own software choices and ask
yourself if you always choose something entirely on technical merit.

And, to be honest, eudev does not *have* to do anything different. If it
provides roughly the same functionality as udev (minus new APIs) then it
serves its purpose and is good enough for those users who use it. There
are many examples of alternatives of one software or another that provide
roughly the same functionality and yet we don't discard one of them simply
because it is not adding features that make it subjectively better than
the other one.

Also, I don't think it's fair to just write the project off because it has
just been existing, providing the same functionality.  There have been bug
fixes and new releases, isn't that the minimum we expect?  It is certainly
not abandoned and dead as it has been characterised here. Maybe it will
become a proper fork in future and add something that udev doesn't have,
who knows.