On Mon, 23 Feb 2009 03:15:03 +0100
Luca Barbato <lu_zero@g.o> wrote:
> 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...

...assuming the metadata cache is valid. That isn't always the case.

> 2- The user will get unpredictable behavior, but portage tell you
> when upgrading is needed...

Not if the version you'd need to do metadata generation is ~arch it
doesn't.

> 3- you'd have to disable them

Yes, tell everyone to disable all the overlays that make use of a few
features only in ~arch package managers... That'll work...

> 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

...which it can't do, because it doesn't know 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.

file(1) can't parse ebuilds. Only an ebuild implementation can parse
ebuilds, and only if it already knows the EAPI.

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

There's no surprise at all. It's extremely clear.

-- 
Ciaran McCreesh