1 |
Fabian Groffen wrote: |
2 |
> On 18-10-2009 14:31:15 +0200, Fabian Groffen wrote: |
3 |
>> On 18-10-2009 13:57:10 +0200, Tomáš Chvátal wrote: |
4 |
>>> Hi, |
5 |
>>> You know i am totaly supporting prefix but i have one point. |
6 |
>>> Why on earth portage simply does not detect the prefix enviroment is being run |
7 |
>>> and then INTERNALY switch D->ED and other variables. It would be much easier |
8 |
>>> that way to migrate all stuff in portage instead of doing this || shebang. |
9 |
>>> Mostly when it is done by eclasses its quite cool, but when you get into |
10 |
>>> changing lots of ebuilds its quite hard for maintaining. |
11 |
>>> |
12 |
>>> Even the multilib overlay guys rather modify the portage than changing a load |
13 |
>>> of ebuilds. |
14 |
>> Of course we would like to do that, but that was rejected for EAPI=3, so |
15 |
>> it will at least take until EAPI=4 is implemented, which is not the |
16 |
>> forseeable future, given that EAPI=3 isn't a fact yet either. |
17 |
> |
18 |
> I was just informed that it is also a possibility to do an EAPI bump |
19 |
> just for these variables, which would mean we can avoid replicating |
20 |
> setting ED and EROOT in ebuilds. |
21 |
> |
22 |
|
23 |
It's possible. |
24 |
|
25 |
> The suggestion was to just introduce EAPI=3 with these variables, and |
26 |
> making everything which is scheduled for current EAPI=3 just EAPI=4. I |
27 |
> was told we could quite quickly have a Portage in the tree that would |
28 |
> set ED and EROOT for EAPI=3 that way. |
29 |
> |
30 |
|
31 |
Maybe 2+prefix is a more describing name? This would avoid changing what |
32 |
EAPI 3 means. |
33 |
|
34 |
> Are there any objections to this? If not, I'd like to put this on the |
35 |
> agenda for the next council meeting. |
36 |
> |
37 |
|
38 |
As the council decided to add new stuff in the last meeting if zac is |
39 |
starting to implement new EAPIs this could go into EAPI 3 too. |
40 |
|
41 |
Regards, |
42 |
Petteri |