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
