On Tue, Mar 6, 2018 at 1:17 PM, Andreas K. Huettel <[email protected]> wrote: > Am Dienstag, 6. März 2018, 02:52:54 CET schrieb Matt Turner: >> EAPI 2 removal bug: https://bugs.gentoo.org/648050 >> >> It seems like tons of churn to update old stable ebuilds to a new >> EAPI, just for its own sake. Take https://bugs.gentoo.org/648154 for >> example. New ebuild added with EAPI 6 bumped from EAPI 2. Otherwise >> functionally identical. Now asking arch teams to retest and >> restabilize. Multiply by 100 or more. > > OK so here's my personal opinion: > > Is it worth the effort? Yes, see below. > Is it a high priority task? No. > > Is it really that much effort? Well, we're even in the case of EAPI=2 talking > about only 400 ebuilds of 35000 in total. That's roughly 1% of the tree. And > I'd strongly suspect that even without the EAPI update it would make very much > sense to check these 400 old ebuilds and test whether they still work as > intended.
There are plenty of reported bugs to look at. No need to go searching for more :) > What do we gain? > > * Mainly, less stuff to memorize. I'll be throwing a party on the day when the > last EAPI=0 ebuild is gone. (In the retirement home, probably.) This is the argument made by others about the cognitive overhead of remembering all the EAPI differences. If the packages are untouched for ages and don't require maintenance, my claim is that there is no cognitive load to begin with. > * Also, it's not just having a bigger number, but also useful features... > > Why now EAPI=2? > > * EAPI=3 is nearly gone (27 ebuilds left, scheme & java please get a move! :) > * EAPI=2 is the one with the next-least ebuilds. > > While it would be very nice to remove EAPI=0, let's go for easier targets > first; the number of EAPI=0 ebuilds will decrease organically in the meantime. > > [Interestingly, as long as no specific efforts are made, the number of ebuilds > in all deprecated EAPI decreases roughly equally and exponentially. That means > the probability of any old ebuild to be removed within a certain time interval > is a constant as function of time...] This is a great point in favor of *not* bothering to proactively bump EAPI.
