On Tue, Dec 27, 2005 at 01:03:49AM +0000, Ciaran McCreesh wrote: > On Mon, 26 Dec 2005 16:57:07 -0800 Brian Harring <[EMAIL PROTECTED]> > wrote: > | Not saying it's a great idea, but EAPI exists to provide immediate > | transition to incompatible changes instead of the usual "work out a > | semi backwards compatible way, don't use it for 6 months, then deal > | with the bugs". > > Addition of any new dependency filtering criterion is a backwards > incompatible change anyway. If you add, say, [fish:trout] and older > versions of Portage don't recognise [fish:], there's no way for said > older Portage versions to know what to do. Being able to parse > additional DEPEND constructs is not sufficient.
Guessing you're missing how EAPI works. The scenario you're pointing at isn't an issue for EAPI aware portage versions. If portage doesn't know of that EAPI version, it flat out won't do _any_ operations on that package; it's filtered out of available packages. Hell, we don't even store the metadata in the cache- the reasoning being that if we don't know of that EAPI version, there is _no_ gurantee we'll even be processing the metadata dumped from ebuild.sh properly (nor that ebuild.sh will produce proper metadata for that eapi). So... for scenario above, portage sees the differing EAPI, masks the package on it's own- the new dependency format isn't seen, nor processed by portage. Like I said, via EAPI we can effectively break whatever we want format wise, do a total quick cut over without breaking older eapi aware portages (this is the reason eapi exists). Non eapi aware portage's will be boned, but so it goes. They're going to be progressively more screwed the further we go portage wise anyways, so it's something of a lost cause (imo). ~harring
pgp73LMMl2yGl.pgp
Description: PGP signature
