| 1 |
From time to time the topic of deprecating EAPIs comes up and usually |
| 2 |
one suggestion is to keep 0 and start with converting EAPI 1 ebuilds. |
| 3 |
Then someone comes along and asks what is the point? Indeed, a fair |
| 4 |
question. |
| 5 |
|
| 6 |
The following tries to take a different approach to the topic. It's not |
| 7 |
all thought through in detail, but that wont happen anytime soon, |
| 8 |
after all it's on my TODO for long enough. So I present it in the hope |
| 9 |
others will try to poke holes into it or even pick it up. |
| 10 |
|
| 11 |
|
| 12 |
EAPI=0 requirement pointless? |
| 13 |
----------------------------- |
| 14 |
|
| 15 |
The EAPI=0 requirement comes from having to provide an update path for |
| 16 |
systems with a package manager without EAPI support. By now we are |
| 17 |
talking about really ancient systems and it's questionable if there is |
| 18 |
any merit in supporting such. |
| 19 |
|
| 20 |
Further the situation is that some of the maintainers of must be EAPI 0 |
| 21 |
ebuilds already moved on as the majority of users will profit from a |
| 22 |
bump. As a result the clean upgrade path is already borked and the |
| 23 |
value of keeping others at EAPI=0 deteriorates further and further. |
| 24 |
|
| 25 |
Forcing EAPI 0 on some maintainers for all eternity doesn't strike me |
| 26 |
as brilliant, quite the opposite frankly. After all new EAPIs are |
| 27 |
supposed to contain bug fixes and new features required to write better |
| 28 |
ebuilds. |
| 29 |
|
| 30 |
|
| 31 |
If all installed PMs supported EAPI? |
| 32 |
------------------------------------ |
| 33 |
|
| 34 |
The issue of an update path is reduced to keeping intermediate |
| 35 |
versions in tree. |
| 36 |
|
| 37 |
Those PMs also support EAPI=1, rendering EAPI=0 obsolete. |
| 38 |
|
| 39 |
|
| 40 |
Base EAPI |
| 41 |
--------- |
| 42 |
|
| 43 |
Systems without having a package manager installed that supports at |
| 44 |
least the 'Base EAPI' aren't considered supported any longer. |
| 45 |
|
| 46 |
Maintainers of system packages can use the Base EAPI without worrying. |
| 47 |
|
| 48 |
Maintainers of system packages can use more recent EAPIs but need to |
| 49 |
take special care. |
| 50 |
|
| 51 |
|
| 52 |
Value of Base EAPI |
| 53 |
------------------ |
| 54 |
|
| 55 |
Maintainers of system packages need to be able to use newer EAPIs |
| 56 |
after some time. They can wait but not forever. built_with_use removal |
| 57 |
is one example, strong vs weak blockers an other. |
| 58 |
|
| 59 |
The value can be based on time ( i.e. after 3 years ) or set by council |
| 60 |
decision. A combination is fine as well. |
| 61 |
|
| 62 |
The value should be kept low enough so the rule "maintainers don't have |
| 63 |
to care about using it" holds. |
| 64 |
|
| 65 |
The need of derived distributions / package managers should be |
| 66 |
considered, ie. let them catch up if necessary. |
| 67 |
|
| 68 |
Security updates should be possible for some time without full updates. |
| 69 |
This extends to other packages as well. So maintainers of critical non |
| 70 |
system packages can use this EAPI as well if they want. |
| 71 |
|
| 72 |
Guess EAPI=2 would be a reasonable compromiss. |
| 73 |
|
| 74 |
|
| 75 |
Deprecation? |
| 76 |
------------ |
| 77 |
|
| 78 |
EAPIs below the base EAPI can be considered deprecated if one desires. |
| 79 |
|
| 80 |
References in devmanual can be removed and so the document be |
| 81 |
simplified. |
| 82 |
|
| 83 |
Once there are only few ebuild of a deprecated EAPI left, it might make |
| 84 |
sense to convert them and add a repoman check so the number of used |
| 85 |
EAPIs is kept reasonable. |
Archives