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

[Ciaran McCreesh <ciaran.mccreesh@googlemail.com>]

[-- Attachment #1: Type: text/plain, Size: 3470 bytes --]

On Mon, 23 Feb 2009 15:46:24 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> >> Apparently we do not have any issue...
> > 
> > ...assuming the metadata cache is valid. That isn't always the case.
> 
> When it isn't?

Every now and again (probably after someone changes eutils...), rsync
mirrors end up shipping a load of stale metadata for parts of the tree.
Portage users probably don't notice, since it just causes a slowdown.

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

No no. You're forcing people to switch to ~arch to be able to use
overlays.

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

No, we don't. That's the entire frickin' point of GLEP 55, and one
that you would do well to understand fully before commenting further.
The way we generate metadata now is massively horrible, and only works
because there aren't any serious global scope differences between
EAPIs. We can't make any global scope changes to future EAPIs because
it breaks current metadata generation. Right now it's safe to pretend
EAPI 0 until the real EAPI is worked out, but that won't hold in the
future -- as soon as global scope changes come along, there's no safe
EAPI that can be assumed, even if we didn't have to worry about
breaking existing package managers.

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

It's already *way* more complicated than that. Extracting metadata
requires a full bash 3 implementation along with a considerable amount
of supporting code.

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

Most users don't run ~arch, and do use overlays. So no, this will affect
normal user workflow.

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

Again, you're not getting it. Doesn't matter how up to date your
package manager is. You can't find out the EAPI unless you already know
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.
> 
> Not that much.

How is '.ebuild-3' being used to specify version 3 of the ebuild format
in the least bit surprising?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]