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

[Alex Boag-Munroe <ninpo@qap.la>]

On Wed, 13 Sept 2023 at 02:23, Alex Boag-Munroe <ninpo@qap.la> wrote:
>
> >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.
>
> OK a quick qualifier for me as a respondent:
>
> I hate systemd with a passion, a key reason I use Gentoo is openrc and I wholeheartedly am of the belief that Poettering is an arse and systemd becoming defacto/ubiquitous in Linux was a dark day. I have contributed to the gentoo repo and regularly assist in #gentoo on IRC as well as having submitted my fair share of bugs (and suggested fixes for them).
>
> That said, eudev is no hill to die on. The way Gentoo splits out udev from systemd accomplishes the goal of not having systemd "managing" your system, which was the goal of eudev. Also the goal of eudev was to be a DROP IN REPLACEMENT for udev, this is no longer the case. The thrust of the complaints about the removal seems to be "but it's going to be HARD to maintain this in an overlay" which is kinda the point of why it's being binned from ::gentoo: no one wants to do that work for the Gentoo userbase.
>
> "Works on my machine" is an argument to use an overlay, not keep it in ::gentoo where we've already seen 3 duplicate bug reports where it _doesn't_ work on their machine. The upstream "fixes" for libgudev are a stub at best and "quick and dirty" at worst, which is a direct quote from the discussion of how to support libgudev. The PR to fix the API change is 50% "TODO" comments with fallback calls, the other 50% being a version bump and header hack. Folks have posted some absolutely heinous discussions and proposals from the eudev github as "proof" it's being maintained adequately. Stubs and "quick and dirty" fixes aren't things I find suitable for such a fundamental functionality of my system and I say this as a former eudev user.
>
> eudev is no longer viable as something that provides virtual/libudev, that is its entire reason for existence in the ::gentoo repo.
>
> I've read every single post on this thread, the comparisons to Firefox vs Chrome are utterly ridiculous, both are regularly maintained upstream and both still provide Web Access as people expect AND both have active package maintainers. It is safe to say that at time of writing eudev is not delivering on its drop in promise however little WHAT it doesn't satisfy concerns YOU as a complainer. For ::gentoo the entire userbase has to be considered.
>
> The Gentoo team deserve precisely zero of the crap they're getting for this decision. Either step up as a maintainer if it matters to you so much, or maintain your own overlay if you only care about the things that matter to you, which is a lesser undertaking of work than someone keeping it viable for ::gentoo as a whole where working behaviour MATTERS for packages that depend on virtual/libudev.
>
> If it doesn't matter for you, overlay it, turn off sticky-tags and if you have things that depend on libgudev, mask versions that want sticky-tags and it's an exercise for the user when that's no longer possible.  I assure you at some point it will become no longer possible.
>
> To call back to my intro, eudev gives nothing that being able to pluck udev from systemd gives, which Gentoo is able to do with aplomb.  No systemd for me, openrc forever, cold dead hands etc.  If that changes then that's a different discussion, whether eudev gets forked and revived or a new udev fork happens. Until then I suggest a lot of folks need to unbunch some underwear and either (in order of preference): get over it and switch to openrc with systemd udev,  overlay with relevant USE flags and self maintenance, or volunteer to maintain properly the sys-fs/eudev package which not only includes keeping up with upstream but also delivering on the promise that it can fulfill virtual/libudev.
>
> --
> Ninpo, known idiot
AND ANOTHER THING...
https://lists.freedesktop.org/archives/systemd-devel/2020-November/045646.html
<- this is not an insignificant functionality change, the tag changes
are there, are significant, thus will be used and behaviour will
depend on those calls being correct.  Anyone still mad about last
rites being issued on eudev clearly don't grasp the broad implications
of half arsing compatibility for an entire user base and are just
annoyed _their_ own world view doesn't match reality.

Yes open source is about choices. Viable ones.