On Wed, May 17, 2006 at 07:44:16PM +0100, Ciaran McCreesh wrote: > On Wed, 17 May 2006 11:13:09 -0700 Brian Harring <[EMAIL PROTECTED]> > 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
pgpeVgMBjRfMo.pgp
Description: PGP signature
