1 |
On 03/08/2012 12:53 PM, Ciaran McCreesh wrote: |
2 |
> On Thu, 08 Mar 2012 12:48:51 -0500 |
3 |
> Michael Orlitzky<michael@××××××××.com> wrote: |
4 |
>> On 03/08/2012 12:28 PM, Michał Górny wrote: |
5 |
>>> And something will need to provide that /usr/bin/eapi4 thing. And |
6 |
>>> that introduces new problems: |
7 |
>> |
8 |
>> I'm just parroting someone else's suggestion; I don't really know |
9 |
>> enough about the details to answer these properly. Not that that will |
10 |
>> stop me. |
11 |
> |
12 |
> It probably should. Although in the early days the model for ebuilds |
13 |
> was that they were scripts that were "executed", nowadays there's so |
14 |
> much support required that it's better to think of ebuilds as being |
15 |
> data. If you did have a /usr/bin/eapi5, it would have to be implemented |
16 |
> as something that invoked the package manager, not as a direct |
17 |
> interpreter. |
18 |
|
19 |
Fair enough, but aren't you arguing the opposite point with Zac? If |
20 |
ebuilds are data, fine, we write EAPI=4 somewhere and be done with it. |
21 |
Anything not having that format is out-of-spec. |
22 |
|
23 |
If they're code, they're code, and we need to execute them somehow. And |
24 |
the reason for the proposal in the first place was that the way we do it |
25 |
now ain't so great, eh? |