On Wed, 17 May 2006 13:43:04 -0700 Brian Harring <[EMAIL PROTECTED]> wrote: | 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?
Not really. A fake package is generated for the virtual (rather than just renaming it to another package), and that gets installed into VDB. | 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). Would still confuse Portage somewhat, at least whilst people still use old style virtuals. | > 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. And it's common sense that we've been using all along on the API issue. | 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 *shrug* If you want that feature in a hurry, you're more than welcome to submit a patch. Otherwise it's considered less important than user mirrors, binaries, sdepend etc. And, uh, the local vars will still work just fine even with break functions. | '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. Sure, no-one sane is going to start using XML ebuilds. They might, however, reasonably want the behaviour of 'inherit' to change. -- Ciaran McCreesh Mail : ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
