On Thu, 14 Sept 2023 at 16:30, Eddie Chapman <ed...@ehuk.net> wrote: > > Alex Boag-Munroe wrote: > > On Thu, 14 Sept 2023 at 15:17, Eddie Chapman <ed...@ehuk.net> wrote: > > > >> Andrew Ammerlaan wrote: > >> <snip> > >> > >>> If someone were to step up and say they are willing to spend their > >>> time and effort maintaining eudev and fixing the open issues then sure > >>> we can keep it, I never said otherwise. However this package has been > >>> maintainer-needed for quite a long time now and no one has stepped > >>> up, at some point someone has to pull the plug. > >> <snip> > >> > >> I am willing to help with the maintenance of eudev and field bug > >> reports, either by preferably assisting another or as sole maintainer if > >> that ended up being the requirement (hopefully not as FWICT there is > >> already one other person volunteered). I would have time enough to be > >> fully commit to this from 1st October onwards. > >> > >> My understanding is that in it's current form it cannot remain because > >> it does not support the new API features expected by libgudev. If > >> someone were to object to keep it for that reason then I'd propose to > >> keep it but marked as incompatible with <= whatever version of libgudev > >> introduced new API support. In this worst case scenario anyone with > >> eudev currently installed would then have a choice of either > >> uninstalling eudev, or uninstalling libgudev and any desktop depending > >> libgudev. Then at the very least all server installations who wish to > >> keep eudev could continue doing so, which I think is a much better > >> outcome than all current eudev users having the proverbial rug pulled > >> from under them. > > > > It's not really libgudev related, it just so happens that libgudev is the > > first thing that's cropped up as using new features added to > > systemd[udev]. > > > > Additionally the current proposals to "provide" such support are just > > stubs or fallback calls, introducing unpredictable/surprising behaviour > > for anything calling that part of the udev API. > > > > Which brings us back to the rationale of keeping a package in ::gentoo > > that's identical in every way to some older outdated version of > > systemd[udev] for the sole purpose of "it doesn't say systemd", now with > > added surprises. > > > > A maintainer would need to be willing to uphold the "provides > > virtual/libudev, honest guv" as well as deliver on the promises it makes > > when it tells pkgconf what version it is. Not doing so is a support and > > user headache later when more things use the new tags interface and subtle > > or even not so subtle bugs creep in, new bugs get opened on b.g.o as well > > as the added burden on #gentoo IRC. > > > > -- > > Ninpo > > > > Yes I've been following with interest the gh issue upstream detailing the > stub efforts and am aware that this approach is highly undesirable to many > for the reasons you mentioned. > > However, I think the prospect of anything in the server arena using these > new API features is very slim indeed, and if individual cases arise it's > easy to prevent them being installed together with eudev in the eudev > ebuild, and if those cases happen to be key system packages well *then* > it's game over for eudev. With my proposal people installing eudev would > have to accept big caveats about it not being guaranteed to work with > everything, there may be unknown bugs, etc. But the undisputable fact and > reality is that right now eudev "works fine" with just about everything > without any show stoppers. > > I know this approach will not be liked by what I would consider purists (I > know not everyone would agree with that characterisation and that's fine > it's purely my own opinion) who want to have an ideal world in the system > but as long as it is only the eudev users this will affect (as everyone > else who wants Gnome or whatever will simply not install eudev, which > won't even be possible for them) I dare say people who want eudev on their > system will be more than happy to accept the caveats. > > Obviously eudev and libgudev right now cannot co-exist. But it would be > good to know; is anyone aware of any other non-desktop packages currently > in tree which have shown any signs/prospect upstream of wanting use the > new udev APIs? > Have you looked at the open issues list on eudev github? It's nothing to do with being a "purist", as time moves on eudev is degrading due to a lack of effort in keeping up with systemd[udev] and not just with this latest tag feature, it just happens to be the one that got focused on for this discussion because it's starting to impact users.
Maintaining a package/package repo for a user base can't be done on emotions, feelings or vibes; technical considerations come into play and as has repeatedly been asked in this thread, other than "I hate systemd it's icky and smells, more like Lennart POOPering amirite" what are the technical reasons for trying to keep eudev stuck together with duct tape and string, today, as opposed to simply lifting systemd[udev] and using that? The tags are the latest issue, they're absolutely not the only one and there's plenty of historical things to fix to actually fill on the promise of "provides virtual/libudev". -- Ninpo
