Gentoo Archives: gentoo-council

From: Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>
To: gentoo-council@l.g.o
Subject: Re: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009
Date: Sun, 22 Feb 2009 23:48:09
Message-Id: 20090222234800.29d64b8d@snowcone
In Reply to: Re: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009 by Luca Barbato
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


File name MIME type
signature.asc application/pgp-signature