On Fri, Aug 06, 2010 at 06:48:31PM +0100, Ciaran McCreesh wrote: > On Fri, 6 Aug 2010 10:27:32 -0700 > Brian Harring <ferri...@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
pgpqKvk7fNErb.pgp
Description: PGP signature
