From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1J4RZV-0005S4-N0 for garchives@archives.gentoo.org; Tue, 18 Dec 2007 01:48:38 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.2/8.14.0) with SMTP id lBI1lhKA023554; Tue, 18 Dec 2007 01:47:43 GMT Received: from shadow.wildlava.net (shadow.wildlava.net [67.40.138.81]) by robin.gentoo.org (8.14.2/8.14.0) with ESMTP id lBI1jlLE021227 for ; Tue, 18 Dec 2007 01:45:47 GMT Received: from [10.0.3.98] (mail.boulder.swri.edu [65.241.78.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shadow.wildlava.net (Postfix) with ESMTP id 738668F42A for ; Mon, 17 Dec 2007 18:45:46 -0700 (MST) Message-ID: <47672664.5070507@gentoo.org> Date: Mon, 17 Dec 2007 18:46:12 -0700 From: Joe Peterson User-Agent: Thunderbird 2.0.0.9 (X11/20071119) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) References: <200712172320.01988.peper@gentoo.org> <47671006.2020808@gentoo.org> <20071218001855.78c1864c@blueyonder.co.uk> <20071218013651.58f4f565@eusebe> <20071218004325.41a3240f@blueyonder.co.uk> <47671CD3.4010709@gentoo.org> <20071218011422.613bb703@blueyonder.co.uk> In-Reply-To: <20071218011422.613bb703@blueyonder.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 9c4896f6-c3e0-46ac-a18b-8f9ec8ed8612 X-Archives-Hash: 7dae8a8ad14c337913b4d6b350868e8c Ciaran McCreesh wrote: > On Mon, 17 Dec 2007 18:05:23 -0700 > Joe Peterson wrote: >> This option is worth thinking about more - there may be satisfactory >> ways to mediate the issues. It is certainly more elegant > > Introducing new parse and format requirements upon bash files is most > definitely not elegant... Everything that currently tries to parse bash > that is itself not bash is full of weird bugs. And imposing weird and > arbitrary requirements about whitespace, positioning etc is far more > prone to developer screwup than the filename approach. I agree that such rules should not be arbitrary or depend on whitespace. It should behave essentially the same as sourcing the file. But I do agree that this is not trivial. What about storing a copy of the EAPI in the Manifest file - when "ebuild ... digest" is done? That way, it will always match the one authoritative "post-source" EAPI setting, since changing the ebuild will require a new digest run anyway. We have control over the format of Manifest, so parsing it can be fast. If Manifest is not a good candidate, put them in an optional "EAPI" file (which can then also be included in the Manifest). If the external EAPI info for an ebuild is not found, then drop back to assuming it does not have a defined pre-source EAPI. This way, we can guarantee that the pre-source EAPI info matches the post-source, since it was derived from it (during the digest step). Forgive me if this idea has already been suggested. > The GLEP's rules are merely to ensure a sane upgrade path. EAPI being > specified in two sets of places will only happen if a developer screws > up and ignores warnings from QA tools. Yes, but I bet we can do better than that. -Joe -- gentoo-dev@gentoo.org mailing list