Re: [gentoo-dev] Paludis and Profiles

[Ciaran McCreesh]

On Wed, 17 May 2006 13:43:04 -0700 Brian Harring <ferringb@×××××.com>
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@g.o mailing list