From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1Er3Vs-0005or-35 for garchives@archives.gentoo.org; Tue, 27 Dec 2005 01:20:28 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jBR1JigD006286; Tue, 27 Dec 2005 01:19:44 GMT Received: from cubert.e-centre.net (morbo.e-centre.net [66.154.82.3]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id jBR1HuUw008525 for ; Tue, 27 Dec 2005 01:17:56 GMT Received: from [10.3.1.19] (helo=barracuda2.stayonline.net) by cubert.e-centre.net with esmtp (Exim 4.50) id 1Er3TP-0006PZ-Nn for gentoo-dev@lists.gentoo.org; Mon, 26 Dec 2005 20:17:55 -0500 X-ASG-Debug-ID: 1135646274-15326-953-0 X-Barracuda-URL: http://10.3.1.19:8000/cgi-bin/mark.cgi Received: from et-pdx-2.site.stayonline.net (unknown [65.200.64.131]) by barracuda2.stayonline.net (Spam Firewall) with ESMTP id 44B8C78D5E for ; Mon, 26 Dec 2005 20:17:55 -0500 (EST) Received: from nightcrawler ([172.16.1.202]) by et-pdx-2.site.stayonline.net (8.12.6/8.12.6) with ESMTP id jBR1Hg5j025998 for ; Tue, 27 Dec 2005 01:17:42 GMT Date: Mon, 26 Dec 2005 17:17:54 -0800 From: Brian Harring To: gentoo-dev@lists.gentoo.org X-ASG-Orig-Subj: Re: [gentoo-dev] Multiple Repo Support Subject: Re: [gentoo-dev] Multiple Repo Support Message-ID: <20051227011753.GD5809@nightcrawler.e-centre.net> References: <43A235AD.6030604@leetworks.com> <200512262109.39704.carlo@gentoo.org> <20051226202833.4c5fe9f9@snowdrop.home> <200512270133.19909.carlo@gentoo.org> <20051227004649.798c7794@snowdrop.home> <20051227005707.GB5809@nightcrawler.e-centre.net> <20051227010349.629ca32b@snowdrop.home> 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: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dkEUBIird37B8yKS" Content-Disposition: inline In-Reply-To: <20051227010349.629ca32b@snowdrop.home> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by Barracuda Spam Firewall at stayonline.net X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=4.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.6644 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Archives-Salt: 440a22cd-cbe5-420c-9f47-559826edff97 X-Archives-Hash: 1e7341f63f0bfd0da15511ae61a08abc --dkEUBIird37B8yKS Content-Type: text/plain; charset=utf8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 27, 2005 at 01:03:49AM +0000, Ciaran McCreesh wrote: > On Mon, 26 Dec 2005 16:57:07 -0800 Brian Harring > wrote: > | Not saying it's a great idea, but EAPI exists to provide immediate=20 > | transition to incompatible changes instead of the usual "work out a=20 > | semi backwards compatible way, don't use it for 6 months, then deal=20 > | with the bugs". >=20 > Addition of any new dependency filtering criterion is a backwards > incompatible change anyway. If you add, say, [fish:trout] and older > versions of Portage don't recognise [fish:], there's no way for said > older Portage versions to know what to do. Being able to parse > additional DEPEND constructs is not sufficient. Guessing you're missing how EAPI works. The scenario you're pointing=20 at isn't an issue for EAPI aware portage versions. If portage doesn't know of that EAPI version, it flat out won't do=20 _any_ operations on that package; it's filtered out of available=20 packages. Hell, we don't even store the metadata in the cache- the reasoning=20 being that if we don't know of that EAPI version, there is _no_=20 gurantee we'll even be processing the metadata dumped from ebuild.sh=20 properly (nor that ebuild.sh will produce proper metadata for that eapi). So... for scenario above, portage sees the differing EAPI, masks the=20 package on it's own- the new dependency format isn't seen, nor=20 processed by portage. Like I said, via EAPI we can effectively break whatever we want format=20 wise, do a total quick cut over without breaking older eapi aware=20 portages (this is the reason eapi exists). Non eapi aware portage's will be boned, but so it goes. They're going=20 to be progressively more screwed the further we go portage wise=20 anyways, so it's something of a lost cause (imo). ~harring --dkEUBIird37B8yKS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDsJZBvdBxRoA3VU0RAhf7AJ9wUyqFT6f6QPXvM9EcqbbpF4SukgCdGBZv RN/OLxvFkg52DFBX9w838YI= =/AGp -----END PGP SIGNATURE----- --dkEUBIird37B8yKS-- -- gentoo-dev@gentoo.org mailing list