On Wednesday 17 May 2006 17:26, 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.
No, a package manager can have many features. However, until it is seen as a candidate for becomming the primary package manager (or when it can function fully as secondary package manager (not being the boss in the installation tree)), the official tree may not rely on those features. Otherwise we get to a situation where the official tree relies on an unofficial package manager. The difference between portage and paludis is that portage is the officially supported package manager. This support is limited to the newest versions, but it is still official. Until the decision is made to make paludis the official package manager it isn't. An unofficial package 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 package effectively forces the use of that package manager. If that non-primary package manager can not coexist with the official package manager, the package effectively blocks the usage of the primary package manager. By blocking the usage of the official package manager, the package becomes unofficial and has no place in the official tree. This is basically to protect the official package manager. This is not because I like portage that much, but to provide some kind of unified direction. I am afraid that allowing various competing package managers would cause a wildfire of incompatible elements in the tree. Therefore 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 packages do not hamper the position of the official package manager. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net
pgpruynfUvXUM.pgp
Description: PGP signature
