On Mon, 23 Feb 2009 00:37:47 +0100
Luca Barbato <lu_zero@g.o> wrote:
> Using either manifests

...which doesn't solve the metadata generation problem at all, and
which doesn't work with existing package managers...

> and or switch sync path is even less invasive

...which goes against the whole point of inventing EAPI, and which
makes the upgrade path a regular pain in the ass...

> if you consider that point raised against the proposal to switch
> extensions every time something changes in the ebuild format is that
> is misleading.

How is it misleading? It shows exactly what's going on.

> > But the former has one distinct disadvantage that the latter
> > does not:  any currently released version of portage does not work
> > correctly with ebuilds having version suffixes it does not
> > recognize. For example, you cannot currently create a Manifest in a
> > package directory containing a file named package-1.0.eapi3.ebuild.
> 
> Portage should warn/die if stray files are present. So the whole
> thing looks to me as a way to harness a bug.

Portage already can't generate manifests correctly if it doesn't support
all EAPIs present... This is obvious; why do you bring up such a
blatantly irrelevant argument?

> As stated before this eapi had been considered a ugly solution
> looking for problems to solve.

As stated before, you're talking nonsense. Which part of the long list
of problems it was created to solve don't you understand?

> > With a format such as .ebuild.eapiX we would avoid these issues.
> 
> Using manifest to have portage validate/invalidate ebuilds works as
> well and is completely transparent.

...and doesn't solve the metadata generation problem, nor does it work
with existing package managers.

> Usually in order to get something changed is the burden of the 
> proponents make it worthy for everybody else. Moreover if the change 
> causes any annoyance, its usefulness has to be considered superior to 
> the damage. We got people that annoyed about this proposal that they 
> stated they'll quit if it is passed.

Boo frickin' hoo. It's a technical necessity, and a few malcontents
threatening to throw their toys out of the pram need to be told to grow
up and deal with reality.

> This proposal is in the migration-paths document, why we shouldn't
> use a less invasive approach, that is using pretty much the same
> principle but doesn't have the shortcoming the extension rename ?

Because your proposal addresses none of the underlying problems which
GLEP 55 was created to solve.

-- 
Ciaran McCreesh