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.60) (envelope-from ) id 1FgQtf-0002rk-VJ for garchives@archives.gentoo.org; Wed, 17 May 2006 18:37:24 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.6/8.13.6) with SMTP id k4HIWx0R002019; Wed, 17 May 2006 18:32:59 GMT Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [204.127.192.82]) by robin.gentoo.org (8.13.6/8.13.6) with ESMTP id k4HILluf004456 for ; Wed, 17 May 2006 18:21:48 GMT Received: from nightcrawler (c-24-21-135-117.hsd1.or.comcast.net[24.21.135.117]) by comcast.net (rwcrmhc12) with SMTP id <20060517182147m120045vtde>; Wed, 17 May 2006 18:21:47 +0000 Date: Wed, 17 May 2006 11:21:27 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Paludis and Profiles Message-ID: <20060517182127.GD30935@nightcrawler> References: <20060516161549.442b4d8a@localhost> <200605171204.33647.pauldv@gentoo.org> <20060517145705.70b1f15a@snowdrop.home> <200605171711.10418.pauldv@gentoo.org> <20060517162628.45ef827a@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="ncSAzJYg3Aa9+CRW" Content-Disposition: inline In-Reply-To: <20060517162628.45ef827a@snowdrop.home> User-Agent: Mutt/1.5.11 X-Archives-Salt: c76cd4f1-79bf-48a5-bfaf-91d06f6821c9 X-Archives-Hash: 5e3426adfcf65fba5aa16d41f096d064 --ncSAzJYg3Aa9+CRW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 17, 2006 at 04:26:28PM +0100, Ciaran McCreesh wrote: > On Wed, 17 May 2006 17:11:04 +0200 Paul de Vrieze > wrote: > | Let me clarify my statement. I don't care about candy spinners. > | Paludis (or any other package manager that is to be integrated into > | gentoo) should basically be able to allow a level of mix and match. > | This means that at the initial import, it can be run on any package > | instead of portage, and the results still be usable for portage > | (possibly after a conversion stage). > |=20 > | This allows testing out the package manager. >=20 > Not realistic. It means that any new package manager can't do anything > new. I'd also like to point out that you can't upgrade to a new Portage > version, install some things, downgrade to an older Portage version and > expect things to carry on working. Actually, you can for .54 and 2.1. The only issue is cache backend=20 changeover, but that's minor (--metadata, or let portage regen on it's=20 own). Paludis has to work with the ebuilds that are in the tree now- if it=20 becomes official, go nuts, redefine the standards as you like, until=20 then it needs to remain ebuild level compatible with portage. Yes it castrates some of the shineys, but portage suffers the same for=20 any non-versioned change. > | > | - No part of the tree, except those that by nature are paludis > | > | specific, may require the usage of paludis instead of portage. > | > | This requirement can only be removed after a decision is made by > | > | the council to retire portage in favour of paludis. > | > > | > Again, insane. EAPI allows ebuilds using things that developers have > | > been after for years (you know, slot and use deps) to be in the > | > tree in such a way that they appear masked to Portage. That's a > | > large part of the point of EAPI. > |=20 > | Let's make clear why I put this in. Basically I am of the opinion > | that until a decision is made to make (in this case) paludis the > | primary package manager, all official packages should work with > | portage. Package masked packages are not considered official. >=20 > What of EAPI masked packages? >=20 > The same situation will occur when newer Portage versions supporting > newer EAPIs are released into p.mask or ~arch. Some packages will end > up relying upon something that isn't the stable package manager. One concern here- EAPI was added to version the ebuild format- as=20 such, *everyone involved* should be defining the new EAPI. Defining=20 one in one project, and having it end up in the tree is a no go. Well aware I used EAPI=3D"prefix" for the prefix branch, but that also=20 was for testing. It has not, nor will it ever touch the tree till=20 when it's agreed upon by folks also. ~harring --ncSAzJYg3Aa9+CRW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEa2mnvdBxRoA3VU0RAhBlAJ9t2eOLmT8ADkKXObVZ4zyKgomcAwCg8t26 7/A2nWtmyXHDKhCnWKzay5s= =c/sA -----END PGP SIGNATURE----- --ncSAzJYg3Aa9+CRW-- -- gentoo-dev@gentoo.org mailing list