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