orbea <or...@riseup.net> writes: > I just want to reiterate that the overlay suggestion is bad and the > LibreSSL overlay is a good example of why.
No it's not. It is not possible to compare a virtual provider against something hard coded into many packages. > 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. This only happens due to LibreSSLs failure to be useful (i.e. compatible). It is significantly harder to do a LibreSSL overlay as OpenSSL reverse deps that are being hoisted into using libs that they are not compatible with reference dev-libs/openssl directly rather than a virtual or two. ~/gentoo/repo$ git grep -F dev-libs/openssl | wc -l 1685 ~/gentoo/repo$ git grep -F sys-apps/systemd-utils | wc -l 30 The virtuals are going nowhere. They still have at least two providers, even without eudev. > 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?) They provide different things. Also, virtuals are extraordinarily low maintenance. > sys-kernel/genkernel (?) I don't see why. > sys-fs/udev-init-scripts > sys-fs/mdadm > net-wireless/bluez I don't see why (if eudev stays useful by staying compatible). > sys-apps/systemd-utils I don't follow. Wouldn't one just need to add a blocker between eudev and systemd-utils[udev]? That can be done in either package, and so, can be done in the eudev one. Please elaborate on all of the above. > 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. And there is literally no developer (AFAIK) interested in dealing with this, because eudev is _useless_, and the effort for it is nonzero. The effort for it can be made very close to zero if upstream was reforked and maintained so that it's close to up-upstream. Doing so would also benefit a handful of other distros such as Void, Alpine and Devuan. If there are minor changes to make for eudev that cannot be made in upstream build systems (see, for instance, the few patches I did for basu) then that means eudev has failed to do its job. Basu is actually a decent example of how a 'reductionist' fork of systemd ought to look like (note that basu is orders of magnitude simpler, though, so the effort for eudev would still be higher). Have a lovely night. >> >> > 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. -- Arsen Arsenović
signature.asc
Description: PGP signature
