On Wed, 17 May 2006 12:06:09 -0700 Brian Harring <[EMAIL PROTECTED]> wrote: | 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).
We're faking new-style virtuals for old-style virtuals, so things end up in vdb that don't have an associated 'real' ebuild. Portage can't unmerge them, and it has some trouble with the reduced-content entries for these too. | > 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 that's exactly it. At what point does something stop being API and start being "someone is doing illegal things with internals"? | 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). Actually, I was planning to handle that one by BREAK_FUNCTIONS (name sucks and is not final), which is kinda like SKIP_FUNCTIONS but rather than skipping, launches an interactive shell. | > Portage still relies upon being able to source ebuilds, even if | > their EAPI isn't supported. | | Paludis doesn't? Nope. Paludis can sanely (as in, treat as EAPI masked) handle ebuilds that bash can't parse. This paves the way for XML-based ebuilds, which as we all know is a critical feature required for enterprise support. | 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. Yeah, that's something that would be useful. I was trying to get spb to do it... -- Ciaran McCreesh Mail : ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
