On Fri, Aug 06, 2010 at 07:34:09PM +0100, Ciaran McCreesh wrote: > On Fri, 6 Aug 2010 11:18:46 -0700 > Brian Harring <ferri...@gmail.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.
Currently, a PM that doesn't support EAPI4 will tell you "there is a version available, but I don't support this- upgrade me". Versus current PM's + g55 == "I see no version". *addressing* that would be useful, rather than staying in g55 salesman mode. Like it or not, you switch out the compatibility mechanisms there are delays that go with it while waiting on the implementations to propagate. Now if your solution is "they don't see the version till they upgrade", fine, at least it's accurate and it's stated. This is a fair bit more useful than "there is no issue and it solves world hunger in it's spare time". Grok? > > 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. You checked existing glsa parser to see what they'll do if they get new attributes/tags jammed into the format? Verifying they'll actually ignore the extension is needed rather than hand wavey crap. I'd hope they don't go boom, but there have been issues in the past of this sort. News items are another one that come to mind. Last glance, there wasn't a tag that was jammed into it stating "to even interpret this atom you need to be at least eapi foo"- glep42 surely doesn't cover it. Meaning that a proper implementation will parse it, and quite likely go boom. Meaning either those new version schemes you want can't be used for at least a year in news items. EAPI suffixes addresses one problem. Pretending it solves all is invalid however- GLSA's at the very least probably will have problems, NEWS items most definitely will. > > 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. My stating of restrictions is actually the accurate one. If the rules were what you stated, eclasses would be allowed to set EAPI. Point is, ebuild's set the EAPI themselves. Even your g55 proposal requires this explicitly via the file naming. EAPI in the ebuild combined w/ global functionality never being allowed to screw with EAPI means global scope functionality that doesn't set/influence EAPI is entirely valid. If you're going to claim otherwise, provide an example of per pkg eclasses that fit the requirements stated above that would result in an invalid EAPI. Take an existing ebuild out of the tree to prove it. As for bash syntax, that's wholy unrelated to g33. g33, like normal eclasses, is bound by bash syntax requirements of the current eapi docs. Now removing that limitation might be nice, but it's not core to providing the functionality- as such lay off the bash crap, it's a selling point of g55, it's orthogonal to g33 however. > > 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. And plenty of people hate it too, for the abuse of extensions. The knee jerk claim that the only people who oppose this glep are anti-paludis/exherbo fan boys is the _same_ *bullshit* black/white nonsense y'all railed about it in a seperate part of this thread. Occusing others of fanboy idiocy while pulling the same to excuse away peoples complaints with the glep is hypocritical bullshit. It's very, very tiring, and there are groups on boths sides who pull that shit. Simply put, behaviour of this sort results in people ignoring y'all. Frankly with good reason- may have technical points, but the signal to bullshit ratio is far too high with behaviour of that sort. > > _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. Considering g33 in it's current form doesn't even lay out specifics of per-package eclasses (mabi is working up a glep on that), this is a bit of a bullshit statement. The sole restriction that has been stated thus far for discussion of per package eclasses is "no EAPI setting in the eclass". Labeling that an arbitrary restriction when _you_ pushed the same into global eclasses is at best hypocritical, at worst flat out lieing. Fact is, people want per package eclasses. Additional fact is that both forms of can't screw with EAPI. Final fact is that g55 isn't required for g33- and until you come up with actual, testable examples, I'm done correcting your misstatements. ~harring
pgpQ8DwVkwS1H.pgp
Description: PGP signature
