Ciaran McCreesh wrote:
> On Mon, 17 Dec 2007 18:05:23 -0700
> Joe Peterson <[EMAIL PROTECTED]> wrote:
>> This option is worth thinking about more - there may be satisfactory
>> ways to mediate the issues. It is certainly more elegant
>
> Introducing new parse and format requirements upon bash files is most
> definitely not elegant... Everything that currently tries to parse bash
> that is itself not bash is full of weird bugs. And imposing weird and
> arbitrary requirements about whitespace, positioning etc is far more
> prone to developer screwup than the filename approach.
I agree that such rules should not be arbitrary or depend on whitespace.
It should behave essentially the same as sourcing the file. But I do
agree that this is not trivial.
What about storing a copy of the EAPI in the Manifest file - when
"ebuild ... digest" is done? That way, it will always match the one
authoritative "post-source" EAPI setting, since changing the ebuild will
require a new digest run anyway. We have control over the format of
Manifest, so parsing it can be fast.
If Manifest is not a good candidate, put them in an optional "EAPI" file
(which can then also be included in the Manifest). If the external EAPI
info for an ebuild is not found, then drop back to assuming it does not
have a defined pre-source EAPI.
This way, we can guarantee that the pre-source EAPI info matches the
post-source, since it was derived from it (during the digest step).
Forgive me if this idea has already been suggested.
> The GLEP's rules are merely to ensure a sane upgrade path. EAPI being
> specified in two sets of places will only happen if a developer screws
> up and ignores warnings from QA tools.
Yes, but I bet we can do better than that.
-Joe
--
[EMAIL PROTECTED] mailing list
