On Mon, 23 Feb 2009 00:37:47 +0100 Luca Barbato 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