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