Steven J Long <sl...@rathaus.eclipse.co.uk> posted 1565621.wyyjxms...@news.friendly-coders.info, excerpted below, on Tue, 02 Jun 2009 09:20:34 +0100:
> 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. 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. 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. If the pre-source parsing is slower than the eapi-in-extension (or in filename) solution, so be it. It works technically, and the speed trade- off for non-technical aesthetic sensibilities and semi-technical design is manageable and IMO a worthwhile tradeoff. After all, Gentoo users and developers both obviously have other priorities than installation speed, or they'd be using a binary distribution and packages. 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. While doing that, the speed penalty of in-file EAPI can be mitigated or entirely eliminated as well, so it becomes a non-issue. However, cache structure changes would need debated and are an entirely different issue, while meanwhile, we can formalize the in-file EAPI restrictions now and get on with business, living with the slow-down temporarily if it comes to that. So no, I'm NOT going to attempt to explain why the restriction is such a bad thing, as I don't believe it myself, and there's plenty of others to argue the point better than I could play devil's advocate. 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 while I don't particularly care about _ vs. - and -scm vs lack thereof, problems like allowable bash version features do crop up from time to time, and they'd be MUCH easier handled if the EAPI could handle them without worry about breakage, as it could if it were parseable before sourcing, and I thus see a problem that GLEP55 among other solutions, would solve. Then we're back to my point, that GLEP55 being the only formalized proposed solution, it's likely to be the ultimately accepted one, regardless of the merits, because when it comes down to it, it's the suitably hashed out and formally defined choice out there. > 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! =:^) 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. If there's anyone out there who'd be sufficiently disappointed by that to actually care enough to do something about it, they should consider themselves lucky GLEP55 hasn't been adopted already, and they better get crackin', as every day that goes by without a suitably formalized alternative is a day closer to GLEP55 being adopted simply because it's the only alternative suitably well defined /to/ be adopted. > In the meantime, while we've been discussing this for God knows how > long, we still don't have LDEPENDs, nor do we have elibs which harring > envisaged alongside eclasses and EAPI in the first place. "Broken > process" afaic. I'd tend to agree. > Oh btw, -scm [sic] suffix doesn't add ANYTHING to the existing cvs. > prefix that's been available in portage for at least 3 years; it's a > binary datum, either there or not. "Innovation" is not what I'd call all > this. Indeed. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
