| 1 |
On Mon, 17 Dec 2007 18:05:23 -0700 |
| 2 |
Joe Peterson <lavajoe@g.o> wrote: |
| 3 |
> This option is worth thinking about more - there may be satisfactory |
| 4 |
> ways to mediate the issues. It is certainly more elegant |
| 5 |
|
| 6 |
Introducing new parse and format requirements upon bash files is most |
| 7 |
definitely not elegant... Everything that currently tries to parse bash |
| 8 |
that is itself not bash is full of weird bugs. And imposing weird and |
| 9 |
arbitrary requirements about whitespace, positioning etc is far more |
| 10 |
prone to developer screwup than the filename approach. |
| 11 |
|
| 12 |
> and it avoids another nasty gotcha: that of the pre-source and |
| 13 |
> post-source EAPI disagreeing. Generally, I find that having the same |
| 14 |
> info in two places should be avoided whenever possible. I know the |
| 15 |
> GLEP contains ways of determining the "real" EAPI in this case |
| 16 |
> (post-source), but I can imagine most humans will simply get used to |
| 17 |
> looking at the filename and potentially miss the fact that it doesn't |
| 18 |
> match, and programs that look only pre-source can be mislead. |
| 19 |
|
| 20 |
The GLEP's rules are merely to ensure a sane upgrade path. EAPI being |
| 21 |
specified in two sets of places will only happen if a developer screws |
| 22 |
up and ignores warnings from QA tools. |
| 23 |
|
| 24 |
-- |
| 25 |
Ciaran McCreesh |
Archives