| 1 |
On Sun, Jan 21, 2018 at 11:57 PM, Michael Orlitzky <mjo@g.o> wrote: |
| 2 |
> On 01/21/2018 11:24 PM, Zac Medico wrote: |
| 3 |
>> |
| 4 |
>> Some eclasses like autotools.eclass and vala.eclass generate |
| 5 |
>> version/slot locked dependencies that cause the dependencies of |
| 6 |
>> inheriting ebuilds to change when the versions in the eclasses are |
| 7 |
>> updated. If possible, it would be nice to avoid this version/slot |
| 8 |
>> locking. If not possible, then what should be do? |
| 9 |
>> |
| 10 |
> |
| 11 |
> This changes the deps in stable ebuilds, and was already a no-no. |
| 12 |
> |
| 13 |
> If the dependencies are to remain in the eclasses, then the eclasses |
| 14 |
> should get a new revision when those dependencies change. Afterwards, |
| 15 |
> the consumers can be revbumped and stabilized normally to utilize the |
| 16 |
> new eclass. |
| 17 |
|
| 18 |
While that sounds like the right thing to do in theory, updating all |
| 19 |
consumers of autotools.eclass whenever a new version of automake is |
| 20 |
stabilized is really a lot of work for very little benefit. |
Archives