On Wed, May 17, 2006 at 08:50:32PM +0100, Ciaran McCreesh wrote: > 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.
Instead of on the fly generation of the virtuals pkgs (as pkgcore/portage do), you've flattened them into an actual on disk vdb entry? Re: incompatibility, that can be dealt with by generating a fake ebuild- already generate an env from the looks of it (not seeing anything in RDEPEND/DEPEND however). > | > 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"? Common sense. Paludis wouldn't like what they were doing any more then pkgcore nor portage- modification of a node cannot cause unstated dependency changes, what they were doing was going outside the constant metadata rules binding all ebuild supporting pkg managers (well, the ones that don't want the 100-400x hit from lacking a metadata cache at least). A real example of where portage doesn't support an ebuild in the tree would be welcome (as stated, if it exists it needs fixing). > | 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. Did something similar with ebuild-shell- folks for the most part liked it. Meanwhile... get cracking, you'll see far more local assumptions transitioning between phases then transitioning between groupped merge phases -> groupped unmerge phases > | > 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. 'Cept EAPI was specifically targeted at bash based ebuilds only. Alternative formats (non bash fex), expected folks to solve that issue themselves (since I didn't see a sane general solution to it). For what EAPI is defined as, portage supports it fully. > | 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... I'd suggest it as priority- it's really not all that fun arguging over details lifted from scanning the code, and getting into terminology wars. Get the doc up, folks can evaluate what the actual support costs for paludis are vs assumptions/guesses. ~harring
pgpBtBoz8DPTx.pgp
Description: PGP signature
