On Thu, 18 May 2006 16:54:58 +0200 Paul de Vrieze <[EMAIL PROTECTED]> wrote: | What is then the purpose of paludis. Is its purpose to create a | package manager for a new distro, and the paludis team would like to | use gentoo as a testing ground? | | Or is the purpose of the paludis team to have paludis be an | alternative to portage. In that case it should respect portage, and | make efforts to follow the standard that portage sets.
No single purpose. Approximate goals are usually as follows: * The QA tool part, which has already found a whole load of issues in the tree and has had them fixed. * An alternative to Portage. Paludis itself is distribution agnostic. It can be used on a Gentoo system or on a non-Gentoo system as the user prefers. Paludis does not attempt to emulate every last oddity of Portage. It does not attempt to be usable in parallel with Portage, since that would prevent any useful features from being added. It *does* attempt to work with all existing ebuilds. It *can* read Portage-generated VDB, although at this stage we're strongly encouraging people not to try that, because there will probably be a few bugs... | What I have done is stated: | - Why paludis accomodations are too early at this moment By the same argument, icc shouldn't be in the tree. | - Why package managers should not have their own profiles Yes, very nice in theory. Unfortunately, Portage requires a whole load of Portage stuff in its profile, so that's not an option. | - What categories of package managers can exist (candidate | replacement, secondary, third-party) This categorisation is a false trichotomy. There is no reason for it to exist, and it has no value. | - That there can only one primary package manager | - What requirements exist for a secondary package manager | - What requirements exist for a candidate replacement package manager Again, nonsense based upon some random arbitrary segregation you're attempting to make that has no real world relevance. | One of the biggest issues for amd64 is the fact that packages can not | be installed for particular architectures or in paralel. An | alternative package manager could offer a way that while allowing | each architecture to be installed separately, it merges the files | into one package and maintains separate files that record which | subpackage which file belongs to. This way portage can remove the | package, see that it's there and even verify the contents. It only | can not itself provide multi architecture installation. Can't be done without huge ebuild changes. And were we to do that, we'd just implement multi-abi properly. Which would be trivial with Paludis and impossible with Portage. | Another thing is reverse dependencies. This is missing from portage, | but a feature that could well be implemented independent of the | on-disk system. Yes, carry on looking at the small picture. It's really really interesting! -- Ciaran McCreesh Mail : ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
