Re: [gentoo-dev] Multiple Repo Support

[Brian Harring]

On Tue, Dec 27, 2005 at 01:03:49AM +0000, Ciaran McCreesh wrote:
> On Mon, 26 Dec 2005 16:57:07 -0800 Brian Harring <ferringb@g.o>
> 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