From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1MBTV8-0003dJ-Ui for garchives@archives.gentoo.org; Tue, 02 Jun 2009 12:53:59 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D319FE033F; Tue, 2 Jun 2009 12:53:57 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 8E95DE033F for ; Tue, 2 Jun 2009 12:53:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 3033266698 for ; Tue, 2 Jun 2009 12:53:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -2.943 X-Spam-Level: X-Spam-Status: No, score=-2.943 required=5.5 tests=[AWL=0.656, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6gCZueabG5n for ; Tue, 2 Jun 2009 12:53:50 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 6C41464DFB for ; Tue, 2 Jun 2009 12:53:49 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MBTUv-00028w-AB for gentoo-dev@gentoo.org; Tue, 02 Jun 2009 12:53:45 +0000 Received: from ip68-231-21-207.ph.ph.cox.net ([68.231.21.207]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 02 Jun 2009 12:53:45 +0000 Received: from 1i5t5.duncan by ip68-231-21-207.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 02 Jun 2009 12:53:45 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: How not to discuss Date: Tue, 2 Jun 2009 12:53:35 +0000 (UTC) Message-ID: References: <20090527210642.6b7b0f21@snowcone> <20090530145613.37514ceb@halo.dirtyepic.sk.ca> <4A21E40A.60500@gentoo.org> <200905311126.00274.bangert@gentoo.org> <1565621.WYyjxmS50y@news.friendly-coders.info> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-21-207.ph.ph.cox.net User-Agent: Pan/0.133 (House of Butterflies) Sender: news Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 74101ba9-cdc0-4744-9b42-0d5a248d2dcc X-Archives-Hash: cd3d7ce77eda6fff3483d71adc8582e7 Steven J Long posted 1565621.WYyjxmS50y@news.friendly-coders.info, excerpted below, on Tue, 0= 2 Jun 2009 09:20:34 +0100: > Personally I favour restricting the EAPI=3D'blah' line (which imo shoul= d > 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. >=20 > 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=20 position mistaken for that of someone else. I actually happen to agree with your statement of opinion as quoted=20 above, now put in my own words, that an in-ebuild EAPI=3D'blah' line (or=20 similar in-ebuild equivalent, shebangs, etc), suitably restricted in=20 position and value, complete with single quotes to avoid escaped-char=20 issues, is sufficient. Either wait a suitable time or change the ebuild=20 extension *ONCE* to ensure all actively supported PMs work with this=20 before the first otherwise disruptive global change (as to say filename=20 version information, but that's a separate issue), and run with it. Plus the in-extension (or in-filename) solution has very similar=20 restrictions. so it's not about the question of adding EAPI restrictions,= =20 that's a given either way. We can just add them to the existing in-file=20 solution and get on with the show, with the same ultimate extensibility=20 benefits and very similar restrictions either way, so we might as /well/=20 just go with simple restrictions on the current solution, and be done=20 with it. If the pre-source parsing is slower than the eapi-in-extension (or in=20 filename) solution, so be it. It works technically, and the speed trade- off for non-technical aesthetic sensibilities and semi-technical design=20 is manageable and IMO a worthwhile tradeoff. After all, Gentoo users and= =20 developers both obviously have other priorities than installation speed,=20 or they'd be using a binary distribution and packages. But, particularly if we're going the *single* extension change route=20 anyway, it's a great opportunity to do any useful cache file format=20 changes, like say, a single unified metadata file for all versions of a=20 package, or all in a category, or adding tags or similar metadata so for=20 instance kmail can show up in both the kde-base and mail client=20 categories. While doing that, the speed penalty of in-file EAPI can be=20 mitigated or entirely eliminated as well, so it becomes a non-issue. =20 However, cache structure changes would need debated and are an entirely=20 different issue, while meanwhile, we can formalize the in-file EAPI=20 restrictions now and get on with business, living with the slow-down=20 temporarily if it comes to that. So no, I'm NOT going to attempt to explain why the restriction is such a=20 bad thing, as I don't believe it myself, and there's plenty of others to=20 argue the point better than I could play devil's advocate. The point I made, however, was entirely separate, that being that=20 regardless of one's personal feelings on GLEP55 and the merits of its=20 implementation, we're likely to be stuck with it, as nobody has bothered=20 formulating a properly constructed alternative solution. As for whether there's even a problem, the council did vote that in=20 principle, they did see the problem, and I agree, there are global format= =20 restrictions in the current EAPI due to the /lack/ of specifics in the=20 EAPI assignment rules that ARE a problem in terms of flexibility. So=20 while I don't particularly care about _ vs. - and -scm vs lack thereof,=20 problems like allowable bash version features do crop up from time to=20 time, and they'd be MUCH easier handled if the EAPI could handle them=20 without worry about breakage, as it could if it were parseable before=20 sourcing, and I thus see a problem that GLEP55 among other solutions,=20 would solve. Then we're back to my point, that GLEP55 being the only=20 formalized proposed solution, it's likely to be the ultimately accepted=20 one, regardless of the merits, because when it comes down to it, it's the= =20 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=20 enough, while I'm saying the current solution as-is, is not enough, and=20 needs at least minor changes. I think we're in violent agreement there! =3D:^) I'm simply adding that whatever one's position on GLEP55 and its=20 suitability, given that it's remains the only formally defined proposal=20 after YEARS of debate, it's likely to be the one adopted, for lack of an=20 alternative. The opposition is demonstrating by its actions that it=20 simply doesn't care enough about it to be motivated to provide a=20 sufficiently defined alternative, since it hasn't done so. If there's=20 anyone out there who'd be sufficiently disappointed by that to actually=20 care enough to do something about it, they should consider themselves=20 lucky GLEP55 hasn't been adopted already, and they better get crackin',=20 as every day that goes by without a suitably formalized alternative is a=20 day closer to GLEP55 being adopted simply because it's the only=20 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 al= l > this. Indeed. --=20 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