1 |
On 03/09/2012 08:33 AM, Eray Aslan wrote: |
2 |
> On Fri, Mar 09, 2012 at 08:15:11AM -0800, Zac Medico wrote: |
3 |
>> They may or may not have issues. Our goal is to minimize our |
4 |
>> vulnerability to these kinds of issues as much as possible. Being able |
5 |
>> to obtain the ebuild EAPI without the expense of sourcing it is one |
6 |
>> small step toward this goal. |
7 |
> |
8 |
> EAPI is metadata and is best treated as such. In other words, history |
9 |
> aside, it does not belong inside an ebuild. Making EAPI info part of |
10 |
> the filename does look like a reasonable solution - similar to |
11 |
> seen/replied flags in the filenames in maildir directories. Heck, even |
12 |
> version numbers in an ebuild filename is similar. |
13 |
> |
14 |
> I don't understand why there is a strong objection to it. |
15 |
|
16 |
I have a mild preference for the "parse EAPI assignment" approach, |
17 |
simply because it's the least invasive. That said, ultimately it doesn't |
18 |
make much difference to me whether we parse it from inside the ebuild or |
19 |
from its file name. From my perspective, arguing between these |
20 |
approaches boils down to hair-splitting [1]. |
21 |
|
22 |
[1] http://en.wikipedia.org/wiki/Trivial_objections |
23 |
-- |
24 |
Thanks, |
25 |
Zac |