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 1NBP8T-0004OV-OZ for garchives@archives.gentoo.org; Fri, 20 Nov 2009 08:46:34 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2BA89E0684; Fri, 20 Nov 2009 08:45:45 +0000 (UTC) Received: from amun.cheops.ods.org (amun.cheops.ods.org [82.95.138.191]) by pigeon.gentoo.org (Postfix) with ESMTP id BB317E0684 for ; Fri, 20 Nov 2009 08:45:44 +0000 (UTC) Received: from tefnut.cheops.ods.org ([2001:888:1022:0:211:24ff:fe37:e46e] helo=gentoo.org) by amun.cheops.ods.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1NBP7f-0007sz-3Y for gentoo-dev@lists.gentoo.org; Fri, 20 Nov 2009 09:45:43 +0100 Date: Fri, 20 Nov 2009 09:45:32 +0100 From: Fabian Groffen To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Gentoo Prefix: on EPREFIX, ED and EROOT inside ebuilds Message-ID: <20091120084532.GJ19586@gentoo.org> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <20091018091154.GB464@gentoo.org> <200910181357.10183.scarabeus@gentoo.org> <20091018123114.GG464@gentoo.org> <20091019194459.GY464@gentoo.org> <19197.18013.751396.332003@a1i15.kph.uni-mainz.de> 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 Content-Disposition: inline In-Reply-To: <19197.18013.751396.332003@a1i15.kph.uni-mainz.de> User-Agent: Mutt/1.5.20 (Darwin 8.11.0, VIM - Vi IMproved 7.2) Organization: Gentoo Foundation, Inc. X-Content-Scanned: by amun.cheops.ods.org (Exim Exiscan) using SpamAssassin and ClamAV X-Archives-Salt: 15ab4052-2ab7-42f6-bf04-eddd409b9d00 X-Archives-Hash: f54e090d78b0023fa81bb8778dbf7a0e On 13-11-2009 12:43:25 +0100, Ulrich Mueller wrote: > In its November meeting [1], the council has unanimously expressed > support for this proposal [2]. > > However, there is need for additional discussion. From the council > meeting log I could extract the following open questions: > > 1. What are the implications for non-prefix devs and users? for devs: take note of EPREFIX, ED and EROOT, be aware what they mean and eventually, use them in the right way. This is not hard, since a simple script[3] based on some heuristics can do the work in 98% of the cases right. for users: not an single bit, unless they look inside ebuilds > 2. Should the Prefix team be allowed to do the necessary changes to > ebuilds themselves, or should it be done by the respective > maintainers? The Prefix team is the equivalent of an arch team, only handling a big bunch of arches [4]. Hence, keywording should be out of the question, and just allowed. Adding simple patches (to normal non-critical ebuilds) used to be allowed AFAIR, so I see that as ok too. In other words, like darkside mentioned, I see our activities like those of an arch team. > 3. Are there any backwards compatibility or upgrade path issues for > eclasses that must still accept EAPI 0 (where the new ED, EROOT, > and EPREFIX variables are not defined)? The backward and forward compatability is handled with conditional code like: use prefix || local ED=${D} or [[ -z ${ED} ]] && local ED=${D} Since Zac checked in yesterday blacklisting of EPREFIX, EROOT and ED in the main Portage branch, these variables hopefully soon become protected in the sense that an externally set ED does not result in weird behaviour of a Prefix aware eclass or ebuild when using the latter approach, which is true forward compatible. For your information, this was exactly what I asked for from the council. > 4. EAPI numbering: Would this simply be added as an additional > feature to EAPI 3? Or should we have an intermediate EAPI slot, > e.g. 2.1 or 3 (and current EAPI 3 renamed to 4 in the latter > case)? I don't care about this, but a fast EAPI is necessary to 1) rely on ED not coming from outside, and 2) since we're defining ED, EROOT and EPREFIX anyway, initialise ED and EROOT such that we don't need any conditional code in ebuilds at all (and can just use ED where necessary). > 5. Who is going to write the exact specification (PMS patch) for > this EAPI feature? We agreed that I/Prefix team will give this a shot. > 6. (Any question that I've missed?) I guess most additional questions go beyond, and actually address the real Prefix work, and its implications to Gentoo and many ebuilds, since we have to touch around 2300 ebuilds, most with trivial changes, some with heavy changes (think of the 32 patches that one needs to compile Python...) > Let's start the discussion now, in order to work out these details > before the next council meeting (December 7th). > > Ulrich > > [1] > (topic was discussed from 21:32 to 22:11 in the log's timezone) > [2] > [3] http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/scripts/eapify [4] http://stats.prefix.freens.org/keywords-packages.png -- Fabian Groffen Gentoo on a different level