On Wednesday 17 May 2006 01:15, Danny van Dyk wrote: > > There are several reasons to handle it slightly different: > a) Paludis is a new package manager, not a different kernel nor > userland. > b) We don't need additional packages that need to go into the tree and > which aren't used by any other arch than bsd. > c) We don't need to keyword any packages. > d) Paludis _can_ use existing profiles. There is no problem with that, > and we did this for quite some time already. Interesting part is the > multiple inheritance of profiles and the different (in my eyes > improved) handling of profile configuration. > > In my eyes, these warrant adding a toplevel profile directory.
Your argumentation is unfortunately incomplete. Paludis is a package manager whose development and profiles can be tested largely outside the tree. While having a profile package for paludis might be inconvenient, the functionality is not different. The main point you fail to mention however is that paludis is as yet not complete. At some point in the stabilisation of paludis gentoo has to decide whether paludis will receive some level of official support. At that time tests involving in-tree profiles can be conducted. There are however a number of requirements I want to state that paludis should meet before I consider it a stable portage replacement: - Paludis must be able to handle a standard portage /var/db/pkg tree. This means that paludis can read it, and write it. Enabling mixing portage and paludis up to some degree. - Paludis must work with all current ebuilds, and support all features of portage. This includes recognition of EAPI, and no renaming of the variables used. - 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. - It would be greatly beneficial if paludis would create and use .tbz2 packages, but this is not essential. Below I'll outline some of the consequences. - Paludis may enhance ebuilds by directing the build process into a more efficient behaviour. As long as the ebuild still functions properly on portage, this should not be an issue. Examples would be in-ebuild documentation of use variables, enhanced dependency handling. - Paludis enhanced packages (except paludis related ebuilds) should only be accepted into the tree when it is seen as a stable package manager. - Paludis may choose to handle different format package descriptions (.ebuild.2?). Those can not appear in the official tree though before paludis is recognised as primary package manager. - Overlays can be used for various ways to extend paludis. - The first requirement of reading /var/db/pkg can be interpreted twofold. Either paludis should support it natively (as one of the options), or it should be able to convert from and to the /var/db/pkg format. - It is allowed for out-of-tree package descriptions to require a different installed package database format. Things like paralel installation of 32bit and 64bit packages require this. As yet the tree should not offer this though. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net
pgpV2qvUqiUfw.pgp
Description: PGP signature
