List Archive: gentoo-council
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
Ciaran McCreesh <ciaran.mccreesh@...>
Luca Barbato <email@example.com>
Issues regarding glep-55 (Was: Re: Preliminary Meeting-Topics for 12 February 2009)
Mon, 23 Feb 2009 03:15:03 +0100
Ciaran McCreesh wrote:
> Because your proposal addresses none of the underlying problems which
> GLEP 55 was created to solve.
As said long ago the glep doesn't tell enough:
"The current way of specifying the EAPI in ebuilds is flawed. In order
to get the EAPI the package manager needs to source the ebuild, which
itself needs the EAPI in the first place. Otherwise it imposes a serious
limitation, namely every ebuild, using any of the future EAPIs, will
have to be source'able by old package managers and hence there is no way
to do any of the following:
* Change the behaviour of inherit in any way (for example, to
extend or change eclass functionality).
* Add new global scope functions in any sane way.
* Extend versioning rules in an EAPI - for example, addition of
the scm suffix - GLEP54"
Let's try to start with a common workflow for the user:
- an user with an ancient version of portage syncs
- it requires a package
- it looks at the cache ($portdir/metadata/cache/)
- picks the best entry from the ones showing an eapi it understands
- keeps going.
Apparently we do not have any issue...
1- the cache could get a non compatible change
2- the user triggers a metadata cache regeneration
-> the ebuild is sourced -> portage could fail or do something
3- overlays do not provide metadata cache
4- A package manager different from portage do not use the provided cache.
1- move the incompatible cache out of ancient portage scope (like in a
2- The user will get unpredictable behavior, but portage tell you when
upgrading is needed...
3- you'd have to disable them
Apparently for this side we don't have much to do if we get a valid cache.
Ebuilds have to be added to portage so here the workflow for the developer:
- new ebuild is sourced
- cache is generated
- manifest is built
In this case we have a problem if the source step is a single one,
portage won't know in advance how to behave.
So the first step has to be split in two:
- first portage discovers which is the eapi version
- then behave as defined by the eapi
The problem is that right now sourcing is done by having an instructed
bash. So the simplest way to get the first step done is parsing the
ebuild file with something different like file(1) and then instruct bash
and do the parsing.
This will solve the issue for the developer.
What is proposed in glep-55 seems to aim to solve both issues at the
same time (it isn't stated) by switching file extension every time the
eapi is changed. This is slightly against the principle of the least
surprise and apparently is disliked by enough people to lead the
situation to be discussed in the council.
The fact the glep itself is too much terse doesn't help acknowledging
the problems it aims to solve and the fact it fails to state actual
issues that may need a solution doesn't make it worth the effort and
disruption it would lead.
Gentoo Council Member