[gentoo-dev] Re: How not to discuss

[Duncan]

Steven J Long <slong@××××××××××××××××××.uk> posted
1565621.WYyjxmS50y@××××××××××××××××××××.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