1 |
On 01/21/2018 08:57 PM, Michael Orlitzky 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 |
Sounds good! |
19 |
|
20 |
>> Should we tell users to use the emerge --changed-deps=y option? Maybe |
21 |
>> make --changed-deps=y a default setting? |
22 |
>> |
23 |
> |
24 |
> Our tree shouldn't require a portage-only option to work. Besides, it's |
25 |
> better engineering to have the one person who makes the change alert the |
26 |
> rest of us. Having a million people poll "Did somebody change this? How |
27 |
> about now?" constantly is silly. |
28 |
|
29 |
Okay, think I'll prepare a news item suggesting to use --changed-deps=y |
30 |
if necessary for the initial transition to --dynamic-deps=n. |
31 |
-- |
32 |
Thanks, |
33 |
Zac |