Re: [gentoo-dev] Paludis and Profiles

[Brian Harring]

On Thu, May 18, 2006 at 07:33:27PM +0100, Ciaran McCreesh wrote:
> 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.

<snip>

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

<snip>

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

Please talk to the OSX folk- they would disagree, since 
collision-protect was added to keep gentoo-osx from stomping on the 
primary installation (iow, to keep the secondary from acting like it 
was primary).  Since you also spent a lot of time 'contributing' to 
prefix, I'd expect you'd understand the primary vs secondary role also 
(same with since you've ranted at autopackage).

What he is driving it at is that either paludis is an alternative (yet 
on disk compatible) primary, or it's a secondary- you keep debating 
the compatibility angle, thus the logical conclussion is that it's a 
secondary.


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

Re: vdb, the virtuals hack you've slipped in is paludis choice- you 
design your manager properly, the vdb backend can be swapped out.  In 
other words, collect virtuals on the fly (ala portage/preexisting vdb 
compatible), or convert that backend to a format that has the virtuals 
flattened.

Bluntly, if I can do it in pkgcore, you ought to be able to do it in 
paludis.  It's just a matter of designing your repositories properly, 
you went for on disk virtuals to be faster at the cost of 
compatibility.  Same for copying eclasses in, instead of doing env 
reinstating (you already keep a copy of the env), you went for "well, 
we'll fix it by copying the eclass in"- went for the quick route 
rather then the proper solution (again, if I can do it sanely in 
pkgcore, no reason you can't).

Without clarifying the actual contents level difference (beyond 
collapsing fif/dev into misc), aka the "we can't convert because of 
symlink/dir issues", hard to comment on it- without an example, 
inclined to think it's not a vdb backend difference, just an unmerge 
strategy difference.

~harring