Alex Boag-Munroe wrote: > 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 >
Yes I've looked at the open issues and yes it's not perfect but apart from the libgudev/API issue there is nothing that stops it "working fine" in the vast majority of use cases. I have a very strong view that nobody can tell any other person that they should not run some piece of software no matter what the reason, technical or non-technical. I just find it absolutely deplorable that anyone should try and do that. (However, I would always defend anyone's right to do so, I just strongly disagree with it). In my view, just about the only valid reason to say to someone "you should not run that" is if it is completely broken (e.g. in the sense that it would take an extraordinary effort to get it to build, severe run time errors) The fact is that people might choose to run one piece of software over another for all kinds of reasons including non-technical ones to do with licensing, moral/political beliefs, they like/dislike the developer or the crown or the logo, the list can go on, and trying to judge those non-technical reasons I think is unacceptable. Yes eudev is not on par with udev in terms of API offering and yes it is arguably technically inferior, and there are bugs, and whatever other issues, but for christ sake if people want to run the damn thing just let them be! And even if it's just because they despise systemd then so what?! As I've argued before I don't think anyone can say hand on heart they've always chosen a piece of software to use from a number of alternatives purely based on it being the most "superior" technically. As long as it builds and runs and serves someone's purpose, is not completely abandoned with no hope of any security vulnerability ever being addressed then it's good enough. And I know the next objection someone might make is well that may be, but then don't expect everyone else to do the work or bend over backwards if you want to do something that I deem in my infinite wisdom is stupid. Well, I'm not. The default situation for anyone with what I am proposing is that they will not have eudev installed. But for those that want to, for whatever reason, they will at least be able to, even if they might have a bumpy ride, or sacrifice functionality, or some other software they might want that has become incompatible due to API issues.
