Re: [gentoo-dev] Paludis and Profiles

[Brian Harring]

On Wed, May 17, 2006 at 07:44:16PM +0100, Ciaran McCreesh wrote:
> On Wed, 17 May 2006 11:13:09 -0700 Brian Harring <ferringb@×××××.com>
> wrote:
> | > Paludis can read a Portage-generated VDB. Portage can't read a
> | > Paludis-generated VDB, because Paludis has more features.
> |
> | What features?  You're tracking CONFIG_PROTECT_*, and saving a copy
> | of the eclass (icky solution, but we've discussed that in the past).
> |
> | Beyond that?
>
> Right now, the biggie is virtuals. Attempting to unmerge a virtual that
> was installed via Paludis will confuse the heck out of Portage. There's
> also the whole "handling symlink / directory mismatches" issue, which
> will cause Portage to incorrectly unmerge some Paludis-installed things
> (and, for that matter, some Portage-installed things).

Clarify on virtuals please.  Unless you're mangling the data for 
sym/dir, that's an unmerge time decision (as such it's not vdb data 
specific).


> | > | - Paludis must work with all current ebuilds,
> | >
> | > Portage does not work with all current ebuilds.
> |
> | Name a few please, ones that are portage incompatibility rather then
> | "ebuild no longer works against other ebuilds in the tree".  Can't do
> | anything about the latter, but the former without proof is fud.
>
> We went over this already. Remember webapp.eclass?

Nope.  Assume I'm stupid, don't ask a question when I ask for an 
answer, just state it please- saves both you and I time.

Do recall they were triggering merge -C calls on their own, but that's 
not portage incompatibility as much as doing something dumb...


> | > | and support all features of portage.
> | >
> | > That's insane. Why should we support Portage-style 'candy' spinners?
> |
> | I'd expect he's talking more about stuff like having an ebuild
> | binary/script for walking the phases of an ebuild for development.
>
> Heh. You keep on picking out things that you think will be difficult to
> implement.

Ebuild is easy- I'm pointing at it because the local env issue should 
rear it's head there.  It's also a tool that ebuild devs rely on 
fairly heavily for debugging, as such two birds one stone (locals 
issue you get to investigate closer, and you flesh paludis out 
further).


> | > | This includes recognition of EAPI
> | >
> | > Funnily enough, unlike Portage, Paludis has full EAPI handling.
> |
> | Please clarify on the "full"- since portage relies on EAPI protection
> | already, any issues you see with it's implementation I'd love to know.
>
> Portage still relies upon being able to source ebuilds, even if their
> EAPI isn't supported.

Paludis doesn't?

Related, doc this stuff out please.  Portage differences doc you've 
got is more "we're better cause of xyz"- which is fine, but a low 
level "this is what we do differently" (metadata/security fex) would 
at least allow the possibility of folks being on the same page.


> | Additionally, you went and commited the vars into paludis (doing
> | exactly what I said to do), thank you- lets avoid the 5 emails back
> | and forth in the future however please...
>
> Yes, we now have ~15 lines of useless code. But if that's what it takes
> to make you happy...

Makes that perl patch behave properly for security bug, so yes, it's 
progress- thank you.

~harring