Re: [gentoo-dev] RFC: Reviving GLEP33

[Brian Harring <ferringb@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3355 bytes --]

On Fri, Aug 06, 2010 at 06:48:31PM +0100, Ciaran McCreesh wrote:
> On Fri, 6 Aug 2010 10:27:32 -0700
> Brian Harring <ferringb@gmail.com> wrote:
> > As for 'blatant hack', if you've got no users nor preexisting ebuild 
> > data, you can design whatever you want- it's quite easy to call
> > things blatant hacks if you can design things from scratch and not
> > worry about compatibility.  This is a form of armchair quarterbacking.
> 
> No it isn't, since we've proposed a working alternative that doesn't
> have any of the defects that EAPI in its current form does.
<snip>
> You appear to be confusing "providing a better replacement that we can
> use immediately that doesn't have any of these problems" with
> "bitching".
<snip>
> That's ok. We can migrate to an even better solution now.

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.

Accuracy in details is very useful, including stating the full picture 
rather than just the parts you think sell your particular view.


> The *fact* is, you can't use new version formats with any of your
> proposals,

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.

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 using new global scope functionality or new bash
> functionality introduces all kinds of nasty difficulties and arbitrary
> restrictions of which developers have to be intimately aware.

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?


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.

Pretty much, scream all you want, if people don't like it it's not 
going to go anywhere.  So... keep fighting windmills, or do something 
useful and use what is available to you (existing EAPI semantics).

_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.

Split a thread if you really want to rehash g55 also, rather than the 
thread jacking that is underway.

~brian

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]