On Fri, 15 Sep 2023 01:19:22 +0200 Arsen Arsenović <ar...@gentoo.org> wrote:
> "Eddie Chapman" <ed...@ehuk.net> writes: > > > Not aiming this at you personally but this argument has been made > > more than once in this thread and I personally don't think it > > carries any weight, because it can be levelled at anyone who raises > > an issue about anything. If you don't like it, then just go and > > roll your own. > > ::gentoo is supposed to be a coherent set of packages provided by > Gentoo developers, with a reasonable scope. eudev no longer fits > into the 'coherent' part of that definition, and there are zero > advantages to it over systemd-utils[udev]. > > The _only_ difference between a sys-fs/eudev::eudev and > sys-fs/eudev::gentoo package that would exist if the former were to be > made into an overlay is that Gentoo developers would be responsible > for the latter. There are no Gentoo developers interested in being > responsible for the latter (AFAIK), and there is no tangible benefit > to the latter for any Gentoo developer to latch onto. > > Seeing as there is at least half a dozen people seemingly interested > in maintaining eudev, why not just form an overlay? This way, > virtual/{,lib}udev doesn't get polluted with implementations which > don't fullfil the definition of a virtual provider in ::gentoo, nor > with use-flag hacks, but users which wish to use eudev still have > access to it, and upstream eudev gets half a dozen potential > contributors, which are needed, _badly_. At risk of repeating > myself, I'd like to point out again that the only viable approach for > eudev upstream to take is to re-fork systemd and find a viable way to > stay up-to-date, while fixing up incompatibilities with musl. I've > made proposals a few years ago and restated them in this thread. I just want to reiterate that the overlay suggestion is bad and the LibreSSL overlay is a good example of why. The result is most of the work is redoing things that ::gentoio has already done by copying ebuild changes where actual changes for LibreSSL itself or for packages not compatible with it is a vast minority of the work. With eudev besides maintaining the eudev ebuild itself I suspect other ebuilds the overlay would have to maintain separate copies of are: virtual/libudev virtual/udev (Why are there two of these?) sys-kernel/genkernel (?) sys-fs/udev-init-scripts sys-fs/mdadm net-wireless/bluez sys-apps/systemd-utils And possibly others I missed which have minor changes for eudev, its significantly less work for ::gentoo to keep eudev than for a ::eudev overlay to exist. > > > Of course I know I (and anyone else) can do that. So then what's the > > point of discussing anything then? > > Just because an argument is widely applicable does not make it > invalid. > > Note that this argument is seldom the first resort, since, as you > note, it's not overly productive. Indeed, it was not the first > resort here. sys-fs/eudev has long overstayed the original removal > plan. > > > What's the point of having a big tree with hundreds of packages? Why > > not have a very minimal tree instead and let everyone go and run > > multiple independent repos so we can all do what we want? Then we > > wouldn't have any discussion about what to include and what not. In > > fact maybe that's not a bad idea. > > I'm not sure how to fit this within the context of the thread. > > Have a lovely evening.