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 1FgOTJ-00038B-TA for garchives@archives.gentoo.org; Wed, 17 May 2006 16:02:02 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.6/8.13.6) with SMTP id k4HFwK0Y024614; Wed, 17 May 2006 15:58:20 GMT Received: from callisto.cs.kun.nl ([131.174.33.75]) by robin.gentoo.org (8.13.6/8.13.6) with ESMTP id k4HFmY1A024347 for ; Wed, 17 May 2006 15:48:34 GMT Received: from localhost (localhost [127.0.0.1]) by callisto.cs.kun.nl (Postfix) with ESMTP id 362482E800D for ; Wed, 17 May 2006 17:48:34 +0200 (CEST) From: Paul de Vrieze To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Paludis and Profiles Date: Wed, 17 May 2006 17:48:32 +0200 User-Agent: KMail/1.9.1 References: <20060516161549.442b4d8a@localhost> <200605171711.10418.pauldv@gentoo.org> <20060517162628.45ef827a@snowdrop.home> In-Reply-To: <20060517162628.45ef827a@snowdrop.home> X-Face: #Lb+'V@sGJ;ptgo5}V"W+5OCoo{LZv;bh,s,`WKLi/J)ed1_$0;6X<=?utf-8?q?700LVV/=3BLqPhiDP=5E=0A=09=27f=5Dfnv?=@%6M8\'HR1t=aFx;ePfp{ZQoBe+e)JOQ8T5*(_;mHY+cltLGq<;@$Y,=?utf-8?q?O=5C=24=0A=09Tm=23G6M?=,g![Q62J{na*S9d;R[^8pc%u\aiLqU@`kJtYl"^6pxdW 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; boundary="nextPart7225490.P907CmN8dQ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200605171748.33259.pauldv@gentoo.org> X-Archives-Salt: 972f3afc-1198-4ece-a683-be75c85ed8ef X-Archives-Hash: 0141a031dd24828020df3b2a2415295b --nextPart7225490.P907CmN8dQ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 17 May 2006 17:26, 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). > | > | This allows testing out the package manager. > > 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. No, a package manager can have many features. However, until it is seen as= =20 a candidate for becomming the primary package manager (or when it can=20 function fully as secondary package manager (not being the boss in the=20 installation tree)), the official tree may not rely on those features.=20 Otherwise we get to a situation where the official tree relies on an=20 unofficial package manager. The difference between portage and paludis is that portage is the=20 officially supported package manager. This support is limited to the=20 newest versions, but it is still official. Until the decision is made to=20 make paludis the official package manager it isn't. An unofficial package=20 manager should not limit the usage of the official package manager. > | If they are internals I don't care. If they are part of the API > | exposed to ebuilds then these variables should still be provided. If > | variables are not part of the public API, but still used regularly I > | consider them still part of the API. > > This, funnily enough, is what we're doing. We're supporting things that > are actually used, and things that people might reasonably use. That is fair enough. > | 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. > > What of EAPI masked packages? Nah. If a package requires the use of a non-primary package manager, that=20 package effectively forces the use of that package manager. If that=20 non-primary package manager can not coexist with the official package=20 manager, the package effectively blocks the usage of the primary package=20 manager. By blocking the usage of the official package manager, the=20 package becomes unofficial and has no place in the official tree. This is basically to protect the official package manager. This is not=20 because I like portage that much, but to provide some kind of unified=20 direction. I am afraid that allowing various competing package managers=20 would cause a wildfire of incompatible elements in the tree. Therefore=20 there must be one official package manager that the tree works with. > 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. Portage is however the official package manager. This means that these=20 packages do not hamper the position of the official package manager. Paul =2D-=20 Paul de Vrieze Gentoo Developer Mail: pauldv@gentoo.org Homepage: http://www.devrieze.net --nextPart7225490.P907CmN8dQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3-ecc0.1.6 (GNU/Linux) iD8DBQBEa0XRbKx5DBjWFdsRAmITAJ9bpnTHlYCmwlobTzrH8c1JzuSTRACfQFAv xgu5QhpFcLW2I2MQtQtBgTM= =Ph3i -----END PGP SIGNATURE----- --nextPart7225490.P907CmN8dQ-- -- gentoo-dev@gentoo.org mailing list