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 <[EMAIL PROTECTED]> > 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.
Actually, you can for .54 and 2.1. The only issue is cache backend changeover, but that's minor (--metadata, or let portage regen on it's own). Paludis has to work with the ebuilds that are in the tree now- if it becomes official, go nuts, redefine the standards as you like, until then it needs to remain ebuild level compatible with portage. Yes it castrates some of the shineys, but portage suffers the same for 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. > | > | 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? > > 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 such, *everyone involved* should be defining the new EAPI. Defining one in one project, and having it end up in the tree is a no go. Well aware I used EAPI="prefix" for the prefix branch, but that also was for testing. It has not, nor will it ever touch the tree till when it's agreed upon by folks also. ~harring
pgpviUaPDES9p.pgp
Description: PGP signature
