On Wednesday 17 May 2006 23:34, Christian Birchinger wrote: > I think at the moment there's no plan to replace anything. > There was a simple request to add a profile to make it easier > for some people to develop something. We can talk about > replacing anything later, when there are more intrusive > requests like changing all ebuilds etc.
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. > > I honestly think people are just bringing up the wildest things > just to find another reason to say "no". It Looks a bit like > even good ideas and project have no chance when they come from > "the wrong people". If I only wanted to say No, I would not have needed this many words. Many of what I said applies just as well for pkgcore as for paludis (or any other package manager). What I have done is stated: - Why paludis accomodations are too early at this moment - Why package managers should not have their own profiles - What categories of package managers can exist (candidate replacement, secondary, third-party) - 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 - How paludis developers could enhance paludis such that it could be considered as a candidate portage replacement. - That the decision to replace portage should be made explicitly and should not be forced upon the project by packages in the tree requiring the candidate replacement package manager - That accomodations for a package manager can only be made for candidate package manager or for a secondary package manager (that must encertain full portage compatibility). Let's give some examples of what candidate package managers and secondary package managers can do. 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. Another thing is reverse dependencies. This is missing from portage, but a feature that could well be implemented independent of the on-disk system. Aditional package formats could be supported. The only restriction is that these must not be used in the official tree. They can be used in overlays, or in case of rpm support just used to install rpm packages and achieve a bigger LSB support. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net
pgpX9U90o3R8Q.pgp
Description: PGP signature
