Re: [gentoo-dev] Re: The fallacies of GLEP55

[Ciaran McCreesh]

On Sat, 16 May 2009 21:58:10 +0000 (UTC)
Mark Bateman <couldbe@××××.com> wrote:
> "The current way of specifying the EAPI in ebuilds is flawed"
> That is not defining the problem, that is an opening statement.

That is the problem.

> "In order to get the EAPI the package manager needs to source the
> ebuild, which itself needs the EAPI in the first place."
> It then describes "a" mechanism utilising an ebuild
> (source /usr/portage...) to obtain the EAPI from within the ebuild
> (EAPI=...). Using this method the entire content of GLEP55 is
> accurate.
>
> However, this is not the only method to determine the EAPI of an
> ebuild that exists and as such the viability of GLEP55 as the best
> solution is brought into question

Yes, it is the only method.

> Where is it defined that the ebuild must be sourced 1st?
> Why does the ebuild have to be sourced 1st?

Such things are obviously true to anyone with a basic understanding of
the domain.

> GLEP55 explicitly states that the EAPI to be recorded in the file
> extension, while, as this thread has shown, a number of methods can
> be used to source the EAPI version of the ebuild *without* the need
> of actually source'ing the ebuild (grep, sed, metacache) all of which
> are viable solutions to the problem, the problem that is so obvious
> it doesn't actually have to be defined

Except that that isn't true. With the current rules, an ebuild has to
be sourced to get EAPI. And you can't just say "use the metadata
cache", since the package manager has to know how to generate the
metadata cache in the first place.

Please make sure you're familiar with the basics of how metadata works
before commenting any further.

-- 
Ciaran McCreesh