1 |
W dniu nie, 21.01.2018 o godzinie 20∶24 -0800, użytkownik Zac Medico |
2 |
napisał: |
3 |
> Hi, |
4 |
> |
5 |
> In sys-app/portage-2.3.20, emerge now defaults to --dynamic-deps=n. This |
6 |
> means that unless people explicitly set |
7 |
> EMERGE_DEFAULT_OPTS="--dynamic-deps=y" they're going to have to rebuild |
8 |
> packages any time that the runtime dependencies of those packages need |
9 |
> to be updated. It's possible to trigger these rebuilds using the emerge |
10 |
> --changed-deps=y option. |
11 |
> |
12 |
> Some eclasses like autotools.eclass and vala.eclass generate |
13 |
> version/slot locked dependencies that cause the dependencies of |
14 |
> inheriting ebuilds to change when the versions in the eclasses are |
15 |
> updated. If possible, it would be nice to avoid this version/slot |
16 |
> locking. If not possible, then what should be do? |
17 |
|
18 |
[Disclaimer: this is what I recall from memory, it might not be correct] |
19 |
|
20 |
I think this was discussed at the time when all the things were |
21 |
discussed, and the conclusion was pretty much that there is no valid |
22 |
reason an for eclass to have to retroactively update dependencies |
23 |
in installed packages. |
24 |
|
25 |
We can discuss this in greater detail once someone has a good use case |
26 |
for this. However, FWICS the eclasses mentioned here were already |
27 |
dismissed as build-time only dependencies. |
28 |
|
29 |
> Should we tell users to use the emerge --changed-deps=y option? Maybe |
30 |
> make --changed-deps=y a default setting? |
31 |
|
32 |
No. The idea is that not all dependency changes need to be explicitly |
33 |
propagated. The developer needs to weigh the pros and cons |
34 |
of propagating the change, and choose wisely. There is really no need to |
35 |
enforce a lot of unnecessarily frequent rebuilds because of minor |
36 |
dependency correction that doesn't really apply to the user. |
37 |
|
38 |
-- |
39 |
Best regards, |
40 |
Michał Górny |