Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Thu, 18 May 2006 20:18:24 +0200 Paul de Vrieze <pauldv@g.o>
wrote:
| > * 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.

No, it works with a large part of the tree without modification. I'm
not going to say all, because there're no doubt ebuilds out there that
won't work (just as there are some that won't work with Portage), but
Paludis is quite happy installing system + X + KDE + Gnome + all the
stuff I use.

| 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.

Why? Changes are made to the tree to support other packages all the
time.

| > 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.

Again, you're falling back on meaningless categorisations. There is no
such thing as a primary or secondary package manager.

| > | 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.

And ZSH?

| > | - 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.

I'm sorry, but waiting three years isn't exactly ideal here...

| > | - 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?

Ok, in simpler language: You are pulling this whole "primary /
secondary" thing out of your ass. It has no more meaning than "Package
managers that have the letter 'o' in their name" / "Package managers
that do not have the letter 'o' in their name".

| > | - 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.

*You* are the one making baseless claims. There is no such thing as a
"primary package manager" that is in any way more meaningful than "a
package manager that has the letter 'o' in its name".

| 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).

You can't come up with a reasonable, usable solution that doesn't
require ebuild changes. Nor can you come up with a solution to the VDB
issue that is not an ugly hack -- you don't even know what the
requirements are.

| > | 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.

Again, you're falling back on this whole "secondary package manager"
thing. It has no meaning!

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@g.o mailing list