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
