Gentoo Archives: gentoo-dev

From: Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] RFC: Reviving GLEP33
Date: Fri, 06 Aug 2010 18:34:49
Message-Id: 20100806193409.44493f15@snowcone
In Reply to: Re: [gentoo-dev] RFC: Reviving GLEP33 by Brian Harring
On Fri, 6 Aug 2010 11:18:46 -0700
Brian Harring <ferringb@×××××.com> wrote:
> And by "right now", I assume you meant to say "minimally a year down > the line after a portage is stabled supporting g55 semantics and > resolving any breakage it's usage induces". You know, the same issue > EAPI itself had to go through to ensure that people had a reasonable > chance of getting an appropriate error message and support being in > place.
Uh, no, since GLEP 55 doesn't need users to be using a newer Portage. That is one of the many ways in which it is a much better solution.
> New version formats aren't magically usable the moment g55 lands. At > the very least you're forgetting about bundled glsa's and their > knowledge of atom formats. > > Suppose the next comment will be "they suck, throw them out", but so > it goes.
No, the fix is to give them EAPI suffixes too.
> Realistically, 'the fact is' that a specific scm tag is preferable to > -9999. The reality is that people and the tools have been working > around it without huge issues for a long while. > > Would it be nice having some -scm tag? Sure. Is it worth the > disruption impementing it, and it's dependencies requires? That > arguement you've still not managed to convince people of.
...and 1.2-3 and 1.2-alpha3 style versions, and so on. Remember, it's only a disruption to implement it without GLEP 55.
> The restrictions are "no new global functionality can set or > influence EAPI". Basically the same restriction you forced on > eclasses. It's nasty and arbitrary when I state it, but some how it > is sane when you propose it the same thing?
No, they're not. The restrictions are "no changes that will make older package managers not realise that the EAPI was supposed to have been set to something else". That's not the same thing at all, especially on the "using new Bash syntax" front, and the very fact that you missed that point just goes to illustrate the difficulties involved.
> The thing you're ignoring out of this g55 idiocy is that people don't > particularly seem to want it. There has been an extremely vocal > subgroup of paludis/exherbo devs pushing for it while everyone else > seems to have less than an interest in it. That's generalizing a > bit, but is reasonably accurate.
Uh, no. Plenty of people want it. There has been an extremely vocal subgroup of people who will yell at anything they think is connected to the 'wrong people' pushing against it, thus making everyone else suffer.
> _EITHER WAY_, rather than having g33 get beat down for unrelated > reasons by people screaming they want their pony/g55, g33 can proceed > despite claims to the contrary, and it doesn't require g55 as > ciaran/crew have claimed.
But no-one except you wants GLEP 33. What people want is per-package eclasses *without* all the arbitrary restrictions in GLEP 33. -- Ciaran McCreesh


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


Subject Author
Re: [gentoo-dev] RFC: Reviving GLEP33 Brian Harring <ferringb@×××××.com>