On Mon, Mar 12, 2012 at 07:17:31PM +0100, Ulrich Mueller wrote: > >>>>> On Mon, 12 Mar 2012, Ciaran McCreesh wrote: > > > On Mon, 12 Mar 2012 19:00:32 +0100 > > Ulrich Mueller <u...@gentoo.org> wrote: > >> >>>>> On Mon, 12 Mar 2012, Zac Medico wrote: > >> > If we do go with a variant of GLEP 55, I'd prefer a variant that > >> > uses a constant extension (like .eb) and places the EAPI string > >> > just after the version component of the name. For example: > >> > >> > foo-1.0-r1-eapi5.ebuild > >> > >> This is so ugly... I guess I'll retire the same day when such an > >> abomination gets accepted. ;-) > > > I'm sorry, we're down to "it's ugly and someone already said no and > > I'll throw my toys out of the pram if I don't get my way" as the > > arguments against GLEP 55 now? > > Note the smiley in my posting. And yes, it _is_ ugly.
Worse, it actually makes parsing _worse_ than it already is. What G55 had going for it was ease of filtering out unsupported eapi's. Literally just filter the readdir results. This behemoth Zac is proposing basically requires throwing regex at it, and *is* able to be tripped up since eapi's aren't strictly integers (1-prefix, 4-python, 4-eapi3 if I wanted to intentionally be a dick and break likely non-greedy implementations of the regex). Same angle, embedding it into the version space means that there can be conflicts w/ PN. Basically... embedding it into the versioning like that, besides being ugly as all hell, discards the main benefit g55 had- clear identification of EAPI. It ain't worth it. ~brian
