Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Zac Medico]

On 03/09/2012 07:52 AM, Ian Stakenvicius wrote:
> On 09/03/12 10:41 AM, Zac Medico wrote:
>> On 03/09/2012 07:21 AM, Michael Orlitzky wrote:
>>> The advantage that the eapi function has over a comment is that
>>> it's not magic -- it's just normal bash syntax. So we've
>>> addressed that issue at a small performance cost (we're really
>>> only sourcing the ebuild up to 'exit').
>
>> Also consider the case where a user syncs after not having updated
>> for a couple of months, and the tree contains some ebuilds with
>> EAPIs that are not supported by the currently installed package
>> manager.
>
>
> IIRC we get this already, when the EAPI isn't supported by the version
> of portage installed -- upgrading really old systems won't allow an
> emerge of python-2.7 due to a too-new EAPI, and python-2.7 is needed
> to upgrade to the newer portage.

You're talking about a very specific (unfortunate) upgrade path
breakage. We should keep the discussion focused on more generic cases
that apply to future upgrade scenarios, rather than focusing on past
breakages (though it's obvious that we should also try to avoid such
upgrade path breakages in the future).

Assuming that there is still a viable upgrade path, the package manager
needs resolve dependencies and filter ebuilds based on whether or not
their EAPI is supported. There are basically two ways to do the EAPI
filtering:

1) Access the EAPI from the metadata cache. This assumes that the
package manager is able to validate metadata cache entries for EAPIs
that it does not support, which is a somewhat fragile assumption given
the complexities of cache validation, which involves verification of
ebuilds and additional sources of metadata which may include eclasses
and possibly other files in the future.

2) Parse the ebuild from the ebuild using a pre-defined protocol (parse
EAPI assignment, parse comment, or parse file name as in GLEP 55...).

> I don't see how the EAPI check itself failing and thereby excluding an
> ebuild is much different than the specified EAPI excluding it..?
> Either way, the end user is going to have issues if they don't keep
> their portage up to date.

They may or may not have issues. Our goal is to minimize our
vulnerability to these kinds of issues as much as possible. Being able
to obtain the ebuild EAPI without the expense of sourcing it is one
small step toward this goal.
-- 
Thanks,
Zac