| 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 |
Archives