List Archive: gentoo-council
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
On Mon, 23 Feb 2009 00:37:47 +0100
Luca Barbato <email@example.com> 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.