Matt Turner wrote: > On Tue, Sep 12, 2023 at 5:23 PM Eddie Chapman <ed...@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 > <flop...@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 > <flop...@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.
