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