Re: [gentoo-dev] Paludis and Profiles

[Paul de Vrieze <pauldv@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3184 bytes --]

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: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]