Hi, As far as I can see, the basic problem with EAPI is that in EAPI 0 it isn't specified how to specify the EAPI for an ebuild to be known at pre-filename-parse-, pre-source- and post-source-time. Ancient PM do not assume that there might be ebuilds they do not understand. They only know how to deal with ebuilds that bash cannot parse: mask by corruption.
To me, it looks like the most important point GLEP 55 tries to address is how to have old PMs ignore an ebuild with unsupported EAPI without making too much noise about it. Ok, one variant is to change the extension to get it not being seen as ebuild at all. IMHO, it is neither the "masked by: corruption" nor the "Invalid ebuild name" message being the too-ugly-blocker, but the many red "* error" lines before. So why not look for a way to have old PMs mask such ebuilds "by corruption" or "Invalid ebuild name", but with an additional message as short but explanatory as possible instead of the many ugly error-lines. Looking a bit closer, it isn't portage's python code doing the ugly error printing, but portage's bash-function 'die'. Trying with portage-2.1.6.11 and bash-3.2_p39: Portage does not display any ugly error message for an unsupported ebuild, when this ebuild does 'exit' (either 'exit 0' or 'exit 1') in global scope, so the '|| die' after the 'source $EBUILD' does not get called. And if there is another supported ebuild available for a given package atom, even the 'masked by corruption' message is not shown. So for how to 'exit' in global scope when the PM does not have pre-source EAPI detection. Fortunately, we do have one global function available in each EAPI: 'inherit'. And here does my approach start: I've tried some "eapi.eclass" doing the 'exit' in global scope, eventually displaying a pretty message to inform the user to consider upgrading the PM. This eclass has to be the first eclass inherited in the ebuild, even before setting the actual EAPI. To fulfill this requirement, and to make it easy for the PM to query the EAPI without sourcing, we could specify to have the EAPI definition be the first non-comment line, and to look like: inherit eapi 4 Now when the PM is capable of pre-source EAPI detection, it will set EAPI before sourcing, eapi.eclass can see EAPI already being set and not do the 'exit' in global scope. Or even the PM's inherit-implementation expects to be first called with arguments "eapi 4", and not reading the eapi.eclass at all, so the 'eapi.eclass' does not need to check for anything, just needs to 'exit' when inherited. After that 'inherit eapi X' line, we can specify EAPI X to do *whatever* we want. It even does not need to be bash-sourceable. Yes, it is a compromise, but it looks acceptable to me. Attached is the "eapi.eclass" used for the following test (the 'ewarn' inside can be replaced by something else if necessary): Based on mico-2.3.13.ebuild (EAPI=0), I've added four ebuilds, mico-2.3.13{-r1,-r2,-r3,_live}.ebuild, having these diffs based on the extensions listed in GLEP 55: Incompatible change of inherit: $ diff mico-2.3.13{,-r1}.ebuild 3a4,5 > inherit eapi 4 > inherit "some-local-eclass" New global scope function: $ diff mico-2.3.13{,-r2}.ebuild 3a4,5 > inherit eapi 4 > some-new-global-scope-function Use newer bash features: $ diff mico-2.3.13{,-r3}.ebuild 3a4,8 > inherit eapi 4 > somelocalfunc() { > echo "new bash features in local scope" |& cat > } > echo "new bash features even in global scope" |& cat New version format: $ diff mico-2.3.13{,_live}.ebuild 3a4 > inherit eapi 4 When there is an ebuild available that works with the current PM, the emerge output would look like: $ ACCEPT_KEYWORDS='~x86' emerge -1pv net-misc/mico These are the packages that would be merged, in order: Calculating dependencies | Invalid ebuild name: /usr/portage/net-misc/mico/mico-2.3.13_live.ebuild * Need >=sys-apps/portage-2.3 to support net-misc/mico-2.3.13-r3. * Need >=sys-apps/portage-2.3 to support net-misc/mico-2.3.13-r2. * Need >=sys-apps/portage-2.3 to support net-misc/mico-2.3.13-r1. ... done! [ebuild N ] net-misc/mico-2.3.13 USE="X gtk ssl threads -postgres -qt3 -tcl" 0 kB Total: 1 package (1 new), Size of downloads: 0 kB This is: one additional nice line for each unsupported ebuild, except for the version format change, which shows 'Invalid ebuild name'. But how many such new version formats will exist while there are no other ebuilds with unsupported eapi but compatible version format, and how long do we really plan to support PMs not pre-source reading the eapi? When there is no supported ebuild available, this would look like: $ ACCEPT_KEYWORDS='~x86' emerge -1pv '>net-misc/mico-2.3.13' These are the packages that would be merged, in order: Calculating dependencies | Invalid ebuild name: /usr/portage/net-misc/mico/mico-2.3.13_live.ebuild * Need >=sys-apps/portage-2.3 to support net-misc/mico-2.3.13-r3. * Need >=sys-apps/portage-2.3 to support net-misc/mico-2.3.13-r2. * Need >=sys-apps/portage-2.3 to support net-misc/mico-2.3.13-r1. ... done! !!! All ebuilds that could satisfy ">net-misc/mico-2.3.13" have been masked. !!! One of the following masked packages is required to complete your request: - net-misc/mico-2.3.13-r3 (masked by: corruption) - net-misc/mico-2.3.13-r2 (masked by: corruption) - net-misc/mico-2.3.13-r1 (masked by: corruption) For more information, see the MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. my 2ct... Thanks! /haubi/ -- Michael Haubenwallner Gentoo on a different level
# Copyright 1999-2009 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: $ # # Original Author: Michael Haubenwallner <ha...@gentoo.org> # Purpose: Inform the user that another version of the PM is required to # support this ebuild. # if [[ ${EAPI+set} != 'set' ]]; then if [[ ${PR:-r0} == 'r0' ]]; then ewarn "Need >=sys-apps/portage-2.3 to support ${CATEGORY}/${P}." else ewarn "Need >=sys-apps/portage-2.3 to support ${CATEGORY}/${P}-${PR}." fi exit 0 fi