| 1 |
(Yes, this has EAPI in the title, so that means everyone will chime in) |
| 2 |
|
| 3 |
I'd like to clarify and (eventually) set in stone our ideas of best practices |
| 4 |
when it comes to bumping EAPI for system packages. I was of the belief that |
| 5 |
we had decided that system packages should remain at EAPI 0 for |
| 6 |
backwards-compatibility reasons. It seems, however, that this was never |
| 7 |
written down anywhere and today we find ourselves in a situation where it is |
| 8 |
impossible to bootstrap a Gentoo system from a pre-EAPI-era liveCD due to all |
| 9 |
python versions being EAPI 1 or later. Maybe we don't care anymore, but I'd |
| 10 |
like to know what people think. |
| 11 |
|
| 12 |
system packages* w/ EAPI != 0 |
| 13 |
---------------------------- |
| 14 |
app-shells/bash (EAPI 0 versions available) |
| 15 |
dev-lang/python (all versions) |
| 16 |
sys-apps/grep (EAPI 0 versions available) |
| 17 |
sys-apps/util-linux (EAPI 0 versions available) |
| 18 |
sys-fs/udev (EAPI 0 versions available) |
| 19 |
sys-libs/ncurses (EAPI 0 versions available) |
| 20 |
|
| 21 |
*(the list of system packages was determined by running emerge -ep --nodeps |
| 22 |
@system. your concept of system packages may vary.) |
| 23 |
|
| 24 |
also e2fsprogs-libs is exclusively EAPI 2, but there remains in the tree a |
| 25 |
e2fsprogs ebuild from before the split that is EAPI 0. |
| 26 |
|
| 27 |
So, should we always keep a working EAPI 0 version around? If not, when can |
| 28 |
we drop support for old EAPIs? Your opinions please. |
| 29 |
|
| 30 |
|
| 31 |
-- |
| 32 |
fonts, Character is what you are in the dark. |
| 33 |
gcc-porting, |
| 34 |
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 |
Archives