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

[Luca Barbato <lu_zero@gentoo.org>]

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

When it isn't?

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

disable overlays to UPGRADE to the new portage. Not rocket science...

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

If you are generating the cache you must have a way to know it...

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

file parses quite well avi and mov, ebuild will be anytime more complex 
than that right?

Anyway it isn't a problem since the version of portage doing the work is 
supposed to be up to date, if isn't it will be updated first using the 
normal user workflow that has already been covered by the cache.

> Only an ebuild implementation can parse
> ebuilds, and only if it already knows the EAPI.

That is always the case since you are adding an ebuild and you are 
supposed to have an up to date portage in order to do that.

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

Not that much.

lu

-- 

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