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. > and it avoids another nasty gotcha: that of the pre-source and > post-source EAPI disagreeing. Generally, I find that having the same > info in two places should be avoided whenever possible. I know the > GLEP contains ways of determining the "real" EAPI in this case > (post-source), but I can imagine most humans will simply get used to > looking at the filename and potentially miss the fact that it doesn't > match, and programs that look only pre-source can be mislead. 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. -- Ciaran McCreesh
signature.asc
Description: PGP signature
