| 1 |
Il 03/04/2013 11:07, Ralph Sennhauser ha scritto: |
| 2 |
> On Tue, 2 Apr 2013 16:31:51 +0100 |
| 3 |
> Markos Chandras <hwoarang@g.o> wrote: |
| 4 |
> |
| 5 |
>>> Should we have a stricter rule? Would such a rule help significantly |
| 6 |
>>> reducing the number of EAPI 0 ebuilds? |
| 7 |
>> I believe so. Maybe make repoman scream if you commit an ebuild with |
| 8 |
>> 1<=EAPI<=4 ? |
| 9 |
> I feel strongly against starting with anything but EAPI 0. And I |
| 10 |
> don't consider EAPI 4 old enough to start pestering maintainers about |
| 11 |
> it. |
| 12 |
> |
| 13 |
> What we need is a live cycle of EAPIs to keep things manageable in the |
| 14 |
> long run. We aren't under pressure to get rid of as many as possible |
| 15 |
> ASAP. A simple scheme could be |
| 16 |
> |
| 17 |
> - EAPI becomes second latest |
| 18 |
> - 5 years later repoman warns. |
| 19 |
> - 2 years later repoman errors out. |
| 20 |
> |
| 21 |
> With that scheme EAPI=0 would be due soon. As the "bump to latest |
| 22 |
> eapi" policy isn't that old and seems to have only sunk in a about a |
| 23 |
> year ago, and the myth of still requiring system packages to be EAPI=0 |
| 24 |
> kept a lot of the tree at EAPI=0 for a long time. Fact is EAPI 0 ebuilds |
| 25 |
> are still many, though the number started to crumble significantly |
| 26 |
> lately. So waiting another year before starting actively warn might be |
| 27 |
> appropriate. |
| 28 |
> |
| 29 |
> The important thing is for the council to declare intent and timeframe, |
| 30 |
> so maintainers can plan far ahead. The other thing that became apparent |
| 31 |
> from last discussion is that a slightly low EAPI shouldn't be a card |
| 32 |
> blanch for zealots to touch packages they don't maintain or to file |
| 33 |
> bugs about it. |
| 34 |
> |
| 35 |
|
| 36 |
Hopefully the council will keep in mind that today it's not possible to |
| 37 |
upgrade portage if the system is old enough to require an update from |
| 38 |
python-2.6.5-r2 => :2.7, at least not with a lot of trickery with |
| 39 |
--nodeps and (much more) equally ugly stuff. python-2.6.5-r2 is dated 01 |
| 40 |
May 2010 in ChangeLog. |
| 41 |
|
| 42 |
3 years are pratically more than you can ever hope to support without |
| 43 |
adding manpower dedicated to keep backward compatibility. |
| 44 |
|
| 45 |
Previous reasoning based on the assumption that a) newer api are better |
| 46 |
b) less of them is better c) not being able to upgrade portage mean a |
| 47 |
not upgradable/modifiable gentoo install. |
Archives