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 1Lghp5-00063L-Fy for garchives@archives.gentoo.org; Mon, 09 Mar 2009 15:55:23 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 663CDE0569; Mon, 9 Mar 2009 15:55:22 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 22DA7E0569 for ; Mon, 9 Mar 2009 15:55:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id B7AF16460A for ; Mon, 9 Mar 2009 15:55:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -2.974 X-Spam-Level: X-Spam-Status: No, score=-2.974 required=5.5 tests=[AWL=0.625, 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 thZvr2ygRhmh for ; Mon, 9 Mar 2009 15:55:13 +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 A67D6641A4 for ; Mon, 9 Mar 2009 15:55:12 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Lghon-00065r-GG for gentoo-dev@gentoo.org; Mon, 09 Mar 2009 15:55:05 +0000 Received: from ip68-230-99-190.ph.ph.cox.net ([68.230.99.190]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Mar 2009 15:55:05 +0000 Received: from 1i5t5.duncan by ip68-230-99-190.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Mar 2009 15:55:05 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: Collecting opinions about GLEP 55 and alternatives Date: Mon, 9 Mar 2009 15:54:52 +0000 (UTC) Message-ID: References: <49A472E3.1010204@gentoo.org> <4afbebfe0903090601r5759177bt98639c0c3a61b894@mail.gmail.com> 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-230-99-190.ph.ph.cox.net User-Agent: Pan/0.133 (House of Butterflies) Sender: news Content-Transfer-Encoding: quoted-printable X-Archives-Salt: b846fffe-223c-4806-b9d8-2753f6f3ea07 X-Archives-Hash: e1ce8f08b387a2ec5429a15e33554aeb Jacob Floyd posted 4afbebfe0903090601r5759177bt98639c0c3a61b894@mail.gmail.com, excerpted below, on Mon, 09 Mar 2009 07:01:21 -0600: > Stick EAPI info in the Manifest. The Manifest stores metadata info abou= t > the ebuilds for security and validation purposes, why not add a string > that determines which eapi to use? This then would be generated every > time someone did an "ebuild foo-1.0.ebuild digest". To specify the eapi > version, the developer would specify, as is now, EAPI=3D"bla" in his > ebuild, and grep or similar would be used to extract this when the > digest is created. So ultimately, you leave it in the ebuild, but duplicate it in the=20 manifest... which has its own problems, one of which is that it=20 ultimately falls back to getting the info from the ebuild so it has the=20 same problems that does. The problem with getting EAPI from the ebuild is that as currently speced= =20 in PMS, EAPI cannot be grepped, the ebuild must really be sourced to get=20 it, because it may be changed in eclasses or set and repeatedly changed,=20 etc. And that doesn't really work going forward, because you end up=20 needing to know the EAPI in ordered to source the ebuild properly to get=20 it. (It has only worked thus far because changes have been restricted to= =20 ensure it DOES still work, but that's not practical going forward as it=20 really IS restrictive.) By the time you fix that, you're back at one of the other=20 implementations, effectively decreeing that the EAPI once set (or the=20 EAPI major version, at least, in a major/minor EAPI versioning variant=20 proposal) can't change and putting it either in the ebuild name/ extension, or in a location sufficiently nailed down in the ebuild that=20 it can be scanned directly, line X, or whatever, or at /minimum/=20 narrowing the spec so that it must be early in the ebuild, before=20 inherits, etc (there's a series of post by CiaranM with way more=20 technical detail on exactly how the new requirement would have to be=20 worded). So putting it in the manifest but generated from the ebuild info really=20 doesn't change the problem, leaving us precisely where we were before,=20 except that it may be useful as a component of one of the other=20 solutions, and has been proposed as such in a few of the suggested=20 variants. --=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