| 1 |
On Mon, Jan 22, 2018 at 12:34 PM, Michael Orlitzky <mjo@g.o> wrote: |
| 2 |
> On 01/22/2018 11:37 AM, Mike Gilbert wrote: |
| 3 |
>>> |
| 4 |
>>> If the dependencies are to remain in the eclasses, then the eclasses |
| 5 |
>>> should get a new revision when those dependencies change. Afterwards, |
| 6 |
>>> the consumers can be revbumped and stabilized normally to utilize the |
| 7 |
>>> new eclass. |
| 8 |
>> |
| 9 |
>> While that sounds like the right thing to do in theory, updating all |
| 10 |
>> consumers of autotools.eclass whenever a new version of automake is |
| 11 |
>> stabilized is really a lot of work for very little benefit. |
| 12 |
> |
| 13 |
> Is now a good time to reconsider why we're manually listing stable |
| 14 |
> versions of automake in autotools.eclass? |
| 15 |
|
| 16 |
Yeah, it seems like we might be able to replace it with an unbounded dependency. |
| 17 |
|
| 18 |
For the purpose of automake-wrapper, we might set an environment |
| 19 |
variable using the output of "best_version dev-utils/automake". |
Archives