[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Duncan]

Ciaran McCreesh <ciaran.mccreesh@×××××××××××××.uk> posted
20071220035400.7ef9c32b@×××××××××××××.uk, excerpted below, on  Thu, 20 Dec
2007 03:54:00 +0000:

> On Wed, 19 Dec 2007 20:28:55 -0500
> Richard Freeman <rich@××××××××××××××.net> wrote:
>> Ciaran McCreesh wrote:
>> > On Wed, 19 Dec 2007 18:59:47 -0500
>> > Richard Freeman <rich@××××××××××××××.net> wrote:
>> >> Am I missing something?
>> >
>> > Yes. You're missing all the explanations that have already been given
>> > about why it's impossible to parse ebuilds using anything other than
>> > bash.
>>
>> If the EAPI can be parsed from a filename without using bash, why
>> couldn't it be parsed from a line in the ebuild contents without using
>> bash?
>
> Because a) a future EAPI might want to change EAPI into a function
> rather than a variable, b) there are a zillion ways of setting a
> variable in bash and people already use all of them and c) introducing
> new weird format requirements is silly.

So you're proposing putting the function into the filename?

As he stated, the only credible reason (so far given) bash must be used 
to parse EAPI is if it's dynamic, say a function, and that won't work so 
well in a filename either.  Thus, putting EAPI in the filename pretty 
much eliminates the possibility of it being a function, and we're back to 
the original question, instead of a GLEP allowing it in the filename, why 
not a GLEP specifying the format of that single variable in the file 
contents well enough to parse without bash?

Or, if you are proposing that the pre-source EAPI in the filename could 
be superseded by a function, if that is specifically allowed by the (pre-
source) EAPI defined in the filename, then we are back to what I 
suggested earlier, that you specifically said wasn't necessary (and I 
basically deferred to your judgement), that the pre-source and post-
source EAPI be specifically allowed to be different.

Either the EAPI must be static, so it can be set in the filename, or it 
can be set dynamically, in which case allowing the pre-source and post-
source EAPI to be different actually makes sense.

That said, I do agree that putting it in the filename seems safer, as if 
the PM doesn't understand that EAPI, it can stop right at the filename, 
and doesn't have to worry about parsing the contents of the file itself 
at all, period.  That's safer than having to parse it at least minimally, 
to find out at least the EAPI, before deciding whether it can go 
further.  Thus, regardless of the function thing, I support EAPI in the 
filename as simply safer.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@g.o mailing list