[gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

[Luca Barbato <lu_zero@gentoo.org>]

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...

Now problems:
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 
unpredictable
3- overlays do not provide metadata cache
4- A package manager different from portage do not use the provided cache.

Solutions:
1- move the incompatible cache out of ancient portage scope (like in a 
separate directory)
2- The user will get unpredictable behavior, but portage tell you when 
upgrading is needed...
3- you'd have to disable them
4- unsupported.

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.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero