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 1IrJnf-00013Y-BU for garchives@archives.gentoo.org; Sun, 11 Nov 2007 20:52:59 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.2/8.14.0) with SMTP id lABKq8MA012516; Sun, 11 Nov 2007 20:52:08 GMT Received: from osiris.cheops.ods.org (osiris.cheops.ods.org [80.127.25.226]) by robin.gentoo.org (8.14.2/8.14.0) with ESMTP id lABKoAdp010145 for ; Sun, 11 Nov 2007 20:50:11 GMT Received: from tefnut.cheops.ods.org ([2001:888:1022:0:211:24ff:fe37:e46e] helo=gentoo.org) by osiris.cheops.ods.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IrJkw-0003vG-Pa for gentoo-dev@lists.gentoo.org; Sun, 11 Nov 2007 21:50:10 +0100 Date: Sun, 11 Nov 2007 21:50:05 +0100 From: Fabian Groffen To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild Message-ID: <20071111205005.GB1270@gentoo.org> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <4734D767.1080900@gentoo.org> <20071109220724.GK19739@gentoo.org> <47375195.9060400@gentoo.org> <20071111190803.0f7db931@blueyonder.co.uk> <4737563A.9020303@gentoo.org> <20071111192750.0ae8601c@blueyonder.co.uk> 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 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20071111192750.0ae8601c@blueyonder.co.uk> User-Agent: Mutt/1.5.17 (Darwin 8.10.0, VIM - Vi IMproved 7.1) Organization: Gentoo Foundation, Inc. Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by robin.gentoo.org id lABKq8Nq012516 X-Archives-Salt: ebc29f0c-cdba-409e-9109-9cec8bcd01ed X-Archives-Hash: c573450de33545d89dcce39dd5827082 On 11-11-2007 19:27:50 +0000, Ciaran McCreesh wrote: > On Sun, 11 Nov 2007 21:21:30 +0200 > Petteri R=C3=A4ty wrote: > > > Neither EAPI 0 nor EAPI 1 provide any mechanism for an ebuild to > > > 'die' at global scope. There's simply no way for eclasses to > > > complain that they're being misused. > >=20 > > Well nothing formal but the ebuild developer should pick up ewarn/ech= o > > /whatever messages coming from global scope. That's what we have in > > debug.eclass atm. >=20 > Past experience has shown that those messages will end up being seen by > end users and not being picked up by developers. People changing > eclasses generally don't force a metadata generation for every package > that uses the eclass. >=20 > I suspect that for existing eclasses, the safest way to proceed is to > make a new eclass and move common code into a third eclass. So you'd > have foo.eclass doing EAPI 0 specific stuff and inheriting foo-common, > and foo-eapi1.eclass doing EAPI 1 specific stuff and inheriting > foo-common. This is indeed a very valid point that at least I have ignored for now. In order (for me) not to mix up all kinds of issues here, this is my percieved state with regard to EAPI. EAPI=3D0 is the assumed to be used EAPI when no EAPI is specified in an ebuild. EAPI=3D1 as supported by Portage is like an extension of EAPI=3D= 0 where EAPI=3D0 is like a subset of EAPI=3D1. For this reason current (so= on to be stable?) Portage, and at least the trunk version have EAPI=3D1 support, but can deal with EAPI=3D0 ebuilds fine. In this setting, one could say that eclasses should remain EAPI=3D0, such that all ebuilds will be able to work with them. However, if an EAPI will require some change that makes it backwards incompatible then this won't work any more. What you get is that e.g. for an eclass to work properly it needs to know about variable X, which of course on previous EAPIs does not exist, and hence can result in undesired behaviour. While Ciaran's suggestion would allow some things to work there, it still does not deal with the issue that eclasses should actually be marked with an EAPI level too. (Ideally they also would be part of the digests of an ebuild, but that aside.) A slight alternative to Ciaran's idea here would be to make EAPI1, EAPI2 etc. subdirs in the eclass directory where sort of eclass overloading can be done. This would only solve eclasses not to have an EAPI=3D in it, so they don't overwrite the ebuild's value. --=20 Fabian Groffen Gentoo on a different level --=20 gentoo-dev@gentoo.org mailing list