| 1 |
>>>>> On Sat, 16 Aug 2014, William Hubbs wrote: |
| 2 |
|
| 3 |
> The initial proposal is to change this behaviour so that the PMS |
| 4 |
> default phase functions call all matching phase functions from |
| 5 |
> inherited eclasses in sequence. |
| 6 |
|
| 7 |
> I strongly oppose this change, because I feel it will make our |
| 8 |
> entire tree very unpredictable at best. [...] |
| 9 |
|
| 10 |
+1 |
| 11 |
|
| 12 |
> My counter proposal to this is that we stop calling eclass phase |
| 13 |
> functions automatically, and to minimize the amount of boilerplating |
| 14 |
> we would have to do, we use a variable, such as ECLASS_PHASES which |
| 15 |
> would be defined at the ebuild level and contain a list of the |
| 16 |
> eclass phase functions we want to run automatically. |
| 17 |
|
| 18 |
I'm strongly opposed against this proposal, too. Our current system |
| 19 |
essentially works. Also, already now you can suppress automatic |
| 20 |
calling of phase functions at the eclass level (by not exporting them) |
| 21 |
and at the ebuild level (by defining explicit phase functions). |
| 22 |
|
| 23 |
Ulrich |
Archives