1 |
On 03/05/2017 03:40 AM, Zac Medico wrote: |
2 |
> |
3 |
> A new --with-bdeps-auto=<y|n> option is provided, making it possible to |
4 |
> enable or disable the program logic that causes --with-bdeps to be |
5 |
> automatically enabled. Use --with-bdeps-auto=n to prevent --with-bdeps |
6 |
> from being automatically enabled for installation actions. This is useful |
7 |
> for some rare cases in which --with-bdeps triggers unsolvable dependency |
8 |
> conflicts (and putting --with-bdeps=n in EMERGE_DEFAULT_OPTS would cause |
9 |
> undesirable --depclean behavior). |
10 |
> |
11 |
|
12 |
If I understand correctly, the end result of this is two --flags that |
13 |
combine in a (rather complicated) way to let the user control the |
14 |
default bdeps behavior of both "emerge --update" and "emerge --depclean" |
15 |
separately. I'll try to summarize my understanding: |
16 |
|
17 |
I. emerge --update |
18 |
|
19 |
I.a. Some people want to --update the build dependencies they have |
20 |
installed for e.g. security purposes. |
21 |
|
22 |
I.b. Others don't want build deps pulled in by "emerge --update", |
23 |
because they're using binary packages or because it causes |
24 |
conflicts in the resolver (llvm). |
25 |
|
26 |
II. emerge --depclean |
27 |
|
28 |
II.a. The default behavior is to not remove build-only dependencies |
29 |
because, generally, they will just have to rebuilt again. |
30 |
|
31 |
II.b. However, some people want to remove the build-only deps that |
32 |
aren't strictly in use -- particularly if those build-only |
33 |
deps are not being updated by emerge --update. |
34 |
|
35 |
|
36 |
To choose between those four options... |
37 |
|
38 |
i. --with-bdeps=n and --with-bdeps-auto=y gives you I.a. + II.b. |
39 |
|
40 |
ii. --with-bdeps=n and --with-bdeps-auto=n gives you I.b. + II.b. |
41 |
|
42 |
iii. --with-bdeps=y and --with-bdeps-auto=y gives you I.a. + II.a. |
43 |
|
44 |
iv. --with-bdeps=y and --with-bdeps-auto=n gives you I.a. + II.a. |
45 |
|
46 |
That only gets you three out of the four options. You have to read the |
47 |
fine print to get the other: |
48 |
|
49 |
v. passing no flags explicitly gives you I.b. and II.a. |
50 |
|
51 |
If there's going to be two flags, can't we do better? Why not just name |
52 |
the flags after what we want them to do: |
53 |
|
54 |
--update-bdeps=<y|n> (default: y) |
55 |
|
56 |
--clean-bdeps=<y|n> (default: n) |
57 |
|
58 |
With those two options, it's easy to tell portage exactly what you want. |
59 |
If I don't like the defaults, I can turn one of them off without |
60 |
affecting the other. |
61 |
|
62 |
But what about the --usepkg magic? I think the workaround can be left |
63 |
as-is. When --usepkg is enabled, switch the default for --update-bdeps |
64 |
to "n" unless it is explicitly set. |
65 |
|
66 |
Food for thought. Anyway, thanks for working on this. |