Duncan wrote: > Steven J Long posted: > >> Personally I favour restricting the EAPI='blah' line (which imo should >> simply be single-quoted to avoid escaping issues, but whatever: it's >> easy enough to lex in C, so I fail to see the issue lexing it anywhere >> else) to before the inherit line _in_ _the_ _spec_ since no-one has >> given any reason why we should want to do anything else, and afaik >> repoman will warn about it anyhow. >> >> Could *you* explain to us, why that restriction is such a bad thing? > > Me? I'm afraid you have *me* mistaken for someone else, or at least my > position mistaken for that of someone else. > > I actually happen to agree with your statement of opinion as quoted > above, now put in my own words, that an in-ebuild EAPI='blah' line (or > similar in-ebuild equivalent, shebangs, etc), suitably restricted in > position and value, complete with single quotes to avoid escaped-char > issues, is sufficient. *phew* ;)
btw repoman could easily correct this (given a valid EAPI somewhere in the ebuild) and thus enforce it automatically while not causing the dev any interruption in workflow (beyond a warning.) > Either wait a suitable time or change the ebuild > extension *ONCE* to ensure all actively supported PMs work with this > before the first otherwise disruptive global change (as to say filename > version information, but that's a separate issue), and run with it. > The thing is we don't need to change anything beyond tightening up the PMS. And that's been the issue: that changes to the spec are not accepted from the list, or simply trolled on bugzilla. It's a one-way street (hence the "broken process".) > Plus the in-extension (or in-filename) solution has very similar > restrictions. so it's not about the question of adding EAPI restrictions, > that's a given either way. We can just add them to the existing in-file > solution and get on with the show, with the same ultimate extensibility > benefits and very similar restrictions either way, so we might as /well/ > just go with simple restrictions on the current solution, and be done > with it. > Agreed. > But, particularly if we're going the *single* extension change route > anyway, it's a great opportunity to do any useful cache file format > changes, like say, a single unified metadata file for all versions of a > package, or all in a category, or adding tags or similar metadata so for > instance kmail can show up in both the kde-base and mail client > categories. I am not following why any of those require an extension change? Cache is totally separate to ebuilds. > The point I made, however, was entirely separate, that being that > regardless of one's personal feelings on GLEP55 and the merits of its > implementation, we're likely to be stuck with it, as nobody has bothered > formulating a properly constructed alternative solution. > > As for whether there's even a problem, the council did vote that in > principle, they did see the problem, and I agree, there are global format > restrictions in the current EAPI due to the /lack/ of specifics in the > EAPI assignment rules that ARE a problem in terms of flexibility. So again, change the spec to reflect the reality. Problem solved. Bear in mind that the mangler doesn't even bother looking at the version if the EAPI is not supported. >> In summary: the existing design, including harring's EAPI, suffices for >> all the 'problems' raised. The most we need to do is specify that the >> mangler is allowed to extract the EAPI without sourcing, the >> restrictions that enable this, and that global-scope EAPI functions >> (including a later BASH version) are consequently allowed. > > So you're saying the current solution, with a few minor changes, is > enough, while I'm saying the current solution as-is, is not enough, and > needs at least minor changes. > > I think we're in violent agreement there! =:^) > Yes but those changes are minor and simply to do with PMS. There's nothing portage needs to change, nor are there any implications for mangler developers (it actually makes their life easier) and ebuild authors. > I'm simply adding that whatever one's position on GLEP55 and its > suitability, given that it's remains the only formally defined proposal > after YEARS of debate, it's likely to be the one adopted, for lack of an > alternative. The opposition is demonstrating by its actions that it > simply doesn't care enough about it to be motivated to provide a > sufficiently defined alternative, since it hasn't done so. That's because no change is required, beyond the simple tightening of the spec. Since no GLEP is needed, why on Earth would we bother going through the tortuous process of arguing for one with people who insult us with every line and add nothing else? (in 90% of the replies I get. Yes, that's a made up stat, it could well be more.. ;) And believe me, we get worse on bugzilla. In a nutshell: the GLEP was rejected by consensus last year; the problem was only ever in the PMS, nowhere else. In such a circumstance, no GLEP is required from the "other side." [project] I for one am sick of all the arguing and insults (and yes, I'm aware I tend to give as good as I get;) it's why I went off posting to this list, and to my knowledge it's why quite a few Gentoo devs have left over the past 3 years. Collaboration in my free time does *not* tend to go on being insulted by people who have no clue what they are on about, in my professional opinion, and seem to be more interested in ruining the atmosphere that this list started out with (I recommend reading that far back to anyone who never has. "Manners maketh the man.") The thing is: Gentoo collaboration /could/ be so much more fun, on the list just as much as it already is on IRC. [/project] -- #friendly-coders -- We're friendly but we're not /that/ friendly ;-)
