orbea wrote: > On Tue, 12 Sep 2023 20:23:49 +0300 > Alexe Stefan <stefanalex...@gmail.com> wrote: > >> All this makes me wonder, what really is the reason for this shitshow. >> Something tells me systemd and it's shims will never be without a >> maintainer, regardless of how "popular" they are among gentoo folks. All >> this seems like intentional crippling of systemd alternatives. I don't >> use eudev, but I don't like seeing choice being taken away for such >> paper-thin reasons. The "reasons" listed for the removal are "dead >> upstream", which is false, and open "bugs", most of which are at most >> differences in the default behavior. > > I see 9 issues listed for sys-fs/eudev on the Gentoo tracker. > > I closed 1 as invalid. > > https://bugs.gentoo.org/904741 > > And submitted an upstream PR for another. > > https://bugs.gentoo.org/771705 > https://github.com/eudev-project/eudev/pull/261 > > As for the rest... > > Possibly invalid? > > https://bugs.gentoo.org/667686 (Outdated?) > https://bugs.gentoo.org/711462 > > Possibly outdated? > > https://bugs.gentoo.org/713106 > > And the last 4 need to further investigation. > > https://bugs.gentoo.org/851255 > https://bugs.gentoo.org/770358 > https://bugs.gentoo.org/668880 > https://bugs.gentoo.org/753134 > > > Surprisingly I don't see an issue for sticky-tags. > >> I use a static /dev. That won't just stop working after an update, >> regardless of how much money changes hands. >> >> What does eudev need to do and doesn't do? From discussion in various >> places, I understand that it must set permissions for a devtmpfs and >> maybe create some symlinks. Does it not do that? I know that Lennart >> wants to do everything and do it poorly, but eudev doesn't have to do >> that too. What's the point of a for then? >> >> Overlays were mentioned in this thread. If we remove everything from >> ::gentoo in favor of overlays, what is the point of ::gentoo then? Do >> devs receive prizes based on how many useful packages they remove? Don't >> answer that, we all already know the answer. >> >> There is this quote from "the doctor" on the forums that sums up all >> the insanity: >> >>> As for software depending on what /dev you use, maybe he hasn't been >>> paying >attention but there is no sane reason any userspace application >>> should care how >the entries in /dev are made. There is also no sane >>> reason to break your API >every few months when the good idea fairy >>> comes to call. >> >> As for this: >> >>> Alexe Stefan <stefanalex...@gmail.com> writes: >>> >>>> Must eudev be 100% compatible with all the garbage that gets shoved >>>> into udev to stay in ::gentoo? I don't see mdev being held to that >>>> standard. >> >>> Please don't top-post. >> >>> mdev is not a provider of virtual/libudev and doesn't pretend to be >>> via its pkgconfig file. >> >> What if eudev has to pretend, not because of build or runtime >> failures, but because of needless pesky pkgconfig checks? Should the >> default eudev setup include virtual/libudev in package.provided? I think >> it's better the way it is.
Number of open bugs on its own is really not a good argument for removing a package. sys-fs/udev has about 15 open bugs currently so go figure. But the sticky-tags API issue, to be fair to those who argue for eudev removal, is the main issue, rather than the open bugs. But I want to ask: what are the obstacles to keeping eudev in tree but effectively only for non-desktop use cases? I would love to hear specific reasons from those who are pro-removal why eudev can't exist at least for the server use case. Because the sticky-tags issue only really affects desktop users. And if some important server package comes along in future and wants to use a new udev API feature, then implementing individual features in eudev is more of a realistic proposition than the continual burden of implementing everything. I have many Gentoo server instances out there and I really can't see any sensible reason why eudev can't continue being the udev provider in those scenarios, and surely portage can easily handle marking eudev as not compatible with desktop package installations. Then for desktop users the choice is between eudev or a desktop. Granted it's not ideal but it's better than no eudev at all in tree, and I'm sure there are other similar situations in tree currently where the user has to make a choice between one or the other thing. Now I know the argument that might come back is "well sure, but who's going to do the work needed to be able to make the choice possible?". Well, let's see, maybe someone will volunteer, but I just want to know first is there any insurmountable obstacle that makes that scenario not even possible?
