From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [69.77.167.62] (helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Ko04F-0002Ro-CG for garchives@archives.gentoo.org; Thu, 09 Oct 2008 18:16:55 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 98726E05DE; Thu, 9 Oct 2008 18:15:40 +0000 (UTC) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by pigeon.gentoo.org (Postfix) with ESMTP id 3ED9FE05DE for ; Thu, 9 Oct 2008 18:15:39 +0000 (UTC) Received: by nf-out-0910.google.com with SMTP id c7so79187nfi.26 for ; Thu, 09 Oct 2008 11:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=rDN19Pk9HY7i+P5phZxL5Md4zjcdA+MneYDOUD/ckOM=; b=wkwVciDrZQa3CU7xBkPKWlFoHKs30B4Ven1FLi6W6dUeAaYUfqmSlinuMRocpdPVUn PsejV1uA1TMImh9YZtkLEDAlFFxX/U4MLMp1PJQVLuj40EtmBX3MKkd8UzsU1mlasDBO UarRuZ6SqAbCTHMEt6wRKxZlybBztVrz5ebd0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=xBJNfkecBbGidNrv+noc66igEh5K4392rWHLwIxfwh/ByDWYEVI4RTib1wVu6iISc2 8OuYusOd6NI9TI1bLF9q2E8RcciEL/Dl7I1VXhMKeJpHXQprOGI+9EpSCcs6JZ/edOIo ns2HOzDjT+zE2zjdQDfBPb/um+ZpBMjt78yZg= Received: by 10.210.92.8 with SMTP id p8mr488415ebb.50.1223576137976; Thu, 09 Oct 2008 11:15:37 -0700 (PDT) Received: from localhost (92-235-187-79.cable.ubr18.edin.blueyonder.co.uk [92.235.187.79]) by mx.google.com with ESMTPS id p10sm600726gvf.7.2008.10.09.11.15.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 09 Oct 2008 11:15:37 -0700 (PDT) Date: Thu, 9 Oct 2008 19:15:26 +0100 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] Adding features to Portage that work on top of any EAPI Message-ID: <20081009191526.1f42404e@googlemail.com> In-Reply-To: <20081009174654.GD21770@gentoo.org> References: <20081009174654.GD21770@gentoo.org> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.14.3; x86_64-pc-linux-gnu) 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: multipart/signed; boundary="Sig_/Wxakf5N_2.Ke4fwcaX0NR0P"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: 99a082c4-c3b6-4eb5-85c3-823459c35cd7 X-Archives-Hash: d8f477d36fe857233755e303ce5545d3 --Sig_/Wxakf5N_2.Ke4fwcaX0NR0P Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 9 Oct 2008 19:46:55 +0200 Fabian Groffen wrote: > Currently in Prefix we implemented EAPI as being a set of tokens that > are orthogonal to each other. In other words, while 0, 1 and 2 are > mutual exclusive, "prefix" can be applied to 0, 1, or 2. The result > is something like EAPI=3D"prefix 1". Of course with this approach the > recent introduction of EAPI=3D2, resulted in a problem with eclasses > that do a blind check on the EAPI variable to be e.g. 2. EAPI's defined as being a single value because mixing between EAPIs is in general impossible. For example, I'm guessing prefix might need to do something to econf / the default src_compile/configure functions at some point, so it's not really truly independent. > An alternative is to create multiple new EAPIs, such as prefix-1 or > 1-prefix, containing the Prefix extensions on top of EAPI=3D1. Same > problem when checks on EAPI are done of course, but EAPI then always > consists of a single value. That's the sensible way of doing it... The way things are with EAPIs... The only way you'll get things supported in main tree eclasses is if you get the Council to approve a formal specification of what you want. Unfortunately, they seem reluctant to do that even if you're an official Gentoo project (see kdebuild-1). Is there anything stopping you from formalising your specification of what you need? (The PMS team can probably help with the 'writing formal' bit if necessary, given an informal description.) Could it be done in such a way that non-prefix package managers can do minimal support to get the current /usr behaviour, whilst optionally implementing everything else? If this is the case, the best route's probably to get the whole thing into the next EAPI, start using that EAPI for all your overlay packages and persuade people to include the necessary prefixy things in main-tree eclasses (which they should, once said EAPI is Council approved). > Something that was raised in previous discussions was that maybe the > Prefix extensions don't need an EAPI in itself, but that an ebuild has > to be marked as Prefix-ready through e.g. the recently proposed > PROPERTIES variable, (a horrible hack) in KEYWORDS, or a newly to be > added variable. What's the scope of the changes? I think it'd be easiest to discuss this if you posted an informal summary describing the differences in terms of which bits of PMS are affected. --=20 Ciaran McCreesh --Sig_/Wxakf5N_2.Ke4fwcaX0NR0P Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjuSkEACgkQ96zL6DUtXhHbggCePEqm7JFbFe3VqIno0fgIf6aO GicAnA5tNgGPV5l19jDwaPTEIVtUjbiJ =28sJ -----END PGP SIGNATURE----- --Sig_/Wxakf5N_2.Ke4fwcaX0NR0P--