On Thursday 18 May 2006 18:11, Ciaran McCreesh wrote: > 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.
No problem with that. > * 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. This would make it a third party packaging solution that happens to work to some extend with ebuilds. This would give paludis the big flexibility, not supported by gentoo option. This means that no paludis specific changes must be made to the tree. > > 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... That makes it not suitable to be used in replacement primary packager or secondary packager roles. Leaving the third party role. Gentoo support would thus send the wrong signal. > | 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. Even if that is true, icc has been in the tree since (12 Apr 2002) making it a historical mistake that should be avoided for the future. > > | - 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. Then submit patches to portage to make it profile agnostic. > | - 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. Why and why? > > | - 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. Baseless accusations that are not supported by any argumentation. As long as you don't provide arguments I'll assume that you are out of arguments and try to convince me by baffling me. > > | 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. I can easilly come up with a way to do it without portage changes. It causes some stuff to be compiled too often, but does not break things. I can even invent some way that it does not "conflict" with portage VDB's. Why don't you use your intelligence to find ways to do things that do not conflict with portage (or people). > > | 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! These are just examples. Another example of a secondary package manager would be one that would allow installation of rpm packages in a portage compatible way. I'm not hurt by you calling me names. It just shows that the accusations against you were right. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net
pgpfmUYDzqf12.pgp
Description: PGP signature
