* [gentoo-dev] GLEP 55: another approach: display pretty messages with old PMs
@ 2009-05-28 17:17 Michael Haubenwallner
2009-05-29 8:14 ` [gentoo-dev] " Michael Haubenwallner
0 siblings, 1 reply; 5+ messages in thread
From: Michael Haubenwallner @ 2009-05-28 17:17 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 6290 bytes --]
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
[-- Attachment #2: eapi.eclass --]
[-- Type: text/plain, Size: 513 bytes --]
# Copyright 1999-2009 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
#
# Original Author: Michael Haubenwallner <haubi@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
^ permalink raw reply [flat|nested] 5+ messages in thread
* [gentoo-dev] Re: GLEP 55: another approach: display pretty messages with old PMs
2009-05-28 17:17 [gentoo-dev] GLEP 55: another approach: display pretty messages with old PMs Michael Haubenwallner
@ 2009-05-29 8:14 ` Michael Haubenwallner
2009-05-29 10:42 ` Duncan
0 siblings, 1 reply; 5+ messages in thread
From: Michael Haubenwallner @ 2009-05-29 8:14 UTC (permalink / raw
To: gentoo-dev
On Thu, 2009-05-28 at 19:17 +0200, Michael Haubenwallner wrote:
> 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.
Ohw, the latter would be necessary here, or '4.ebuild' would not be
found.
eapi.eclass could also be renamed to sth. like eapisupport.eclass or
eapivalidation.eclass, to write this way:
EAPI="4"
inherit eapisupport
But then the eclass has to detect which EAPI's are supported by the
running PM to 'exit' upon an unsupported one.
Btw.: What do non-EAPI-aware PMs do with ebuilds using EAPI 1 and 2 -
how become they masked _now_? What did I miss here?
Thanks!
/haubi/
--
Michael Haubenwallner
Gentoo on a different level
^ permalink raw reply [flat|nested] 5+ messages in thread
* [gentoo-dev] Re: GLEP 55: another approach: display pretty messages with old PMs
2009-05-29 8:14 ` [gentoo-dev] " Michael Haubenwallner
@ 2009-05-29 10:42 ` Duncan
2009-05-29 15:17 ` Michael Haubenwallner
0 siblings, 1 reply; 5+ messages in thread
From: Duncan @ 2009-05-29 10:42 UTC (permalink / raw
To: gentoo-dev
Michael Haubenwallner <haubi@gentoo.org> posted
1243584886.27150.33.camel@sapc154.salomon.at, excerpted below, on Fri, 29
May 2009 10:14:46 +0200:
> Ohw, the latter would be necessary here, or '4.ebuild' would not be
> found.
s/4.ebuild/4.eclass/ I assume.
> Btw.: What do non-EAPI-aware PMs do with ebuilds using EAPI 1 and 2 -
> how become they masked _now_? What did I miss here?
They used the old "wait an extended period (loosely speaking, a year)
after initial stabilization of a new feature before use" method. EAPI
was supposed to do away with that, since once EAPI aware PMs could be
assumed (after the year or whatever waiting period), any EAPI a PM didn't
understand was supposed to be rejected.
Except... since an ebuild must presently be sourced to (properly)
determine EAPI, it still doesn't work for changes that break sourcing or
other pre-EAPI processing (like parsing PN and PVR out of the filename),
so the changes allowed with a simple EAPI change are still rather limited.
That's why the change to GLEP55 or alternative, whether in-filename or
in-file-itself, will again require either an extended wait after
introduction (the old way) or at minimum, a one-time change to extension
such that old PM versions don't even see the currently EAPI incompatible
changes.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [gentoo-dev] Re: GLEP 55: another approach: display pretty messages with old PMs
2009-05-29 10:42 ` Duncan
@ 2009-05-29 15:17 ` Michael Haubenwallner
2009-05-29 16:09 ` Duncan
0 siblings, 1 reply; 5+ messages in thread
From: Michael Haubenwallner @ 2009-05-29 15:17 UTC (permalink / raw
To: gentoo-dev
On Fri, 2009-05-29 at 10:42 +0000, Duncan wrote:
> Michael Haubenwallner <haubi@gentoo.org> posted on Fri, 29
> May 2009 10:14:46 +0200:
>
> > Ohw, the latter would be necessary here, or '4.ebuild' would not be
> > found.
>
> s/4.ebuild/4.eclass/ I assume.
Indeed.
> Except... since an ebuild must presently be sourced to (properly)
> determine EAPI, it still doesn't work for changes that break sourcing or
> other pre-EAPI processing (like parsing PN and PVR out of the filename),
> so the changes allowed with a simple EAPI change are still rather limited.
As long as the *whole* ebuild content (including the filename) needs to
be successfully interpreted just for EAPI detection, we will have to
change the extension or wait the extended period for each incompatible
EAPI change. So this full interpretation for EAPI detection doesn't feel
like a good way to go at all.
> That's why the change to GLEP55 or alternative, whether in-filename or
> in-file-itself, will again require either an extended wait after
> introduction (the old way) or at minimum, a one-time change to extension
> such that old PM versions don't even see the currently EAPI incompatible
> changes.
Wouldn't it be possible to avoid both the extension change and another
extended wait period for new incompatible(*) EAPIs, when we do this
early and silent exit hack for unsupported ebuilds with old PMs that
still do full interpretation for EAPI detection?
And after another extended wait period(**), we can start dropping the
silent exit hack, so we finally have switched to EAPI detection without
full interpretation, but still have the .ebuild extension.
(*) The incompatibility of EAPIs must not begin (meaning the bytewise
ebuild content) before the end of both the ebuild's EAPI value
definition and the silent exit hack.
But this IMO is an acceptable compromise.
(**) After this wait period, the incompatibility of EAPIs can start
after the end of the ebuild's EAPI value definition.
Thanks!
/haubi/
--
Michael Haubenwallner
Gentoo on a different level
^ permalink raw reply [flat|nested] 5+ messages in thread
* [gentoo-dev] Re: GLEP 55: another approach: display pretty messages with old PMs
2009-05-29 15:17 ` Michael Haubenwallner
@ 2009-05-29 16:09 ` Duncan
0 siblings, 0 replies; 5+ messages in thread
From: Duncan @ 2009-05-29 16:09 UTC (permalink / raw
To: gentoo-dev
Michael Haubenwallner <haubi@gentoo.org> posted
1243610264.27150.293.camel@sapc154.salomon.at, excerpted below, on Fri,
29 May 2009 17:17:44 +0200:
> Wouldn't it be possible to avoid both the extension change and another
> extended wait period for new incompatible(*) EAPIs, when we do this
> early and silent exit hack for unsupported ebuilds with old PMs that
> still do full interpretation for EAPI detection?
Possibly. I forgot about the context (the inherit eapi.eclass hack) when
I wrote the previous (until /after/ I posted, naturally, probably when
you noticed that 4.ebuild thing too, of course =:^).
But the possibility had been proposed before and I don't remember what
came of it, nor have I been following close enough to know if there's
another caveat somewhere that shoots down the eapi.eclass hack, or not.
I'm sure someone else will supply the reason it didn't go anywhere.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-05-29 16:09 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-05-28 17:17 [gentoo-dev] GLEP 55: another approach: display pretty messages with old PMs Michael Haubenwallner
2009-05-29 8:14 ` [gentoo-dev] " Michael Haubenwallner
2009-05-29 10:42 ` Duncan
2009-05-29 15:17 ` Michael Haubenwallner
2009-05-29 16:09 ` Duncan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox