Re: [gentoo-portage-dev] [PATCH v2] emerge: auto-enable --with-bdeps if --usepkg is not enabled (bug 598444)

[Zac Medico]

On 03/05/2017 07:08 AM, Michael Orlitzky wrote:
> On 03/05/2017 03:40 AM, Zac Medico wrote:
>>
>> A new --with-bdeps-auto=<y|n> option is provided, making it possible to
>> enable or disable the program logic that causes --with-bdeps to be
>> automatically enabled. Use --with-bdeps-auto=n to prevent --with-bdeps
>> from being automatically enabled for installation actions. This is useful
>> for some rare cases in which --with-bdeps triggers unsolvable dependency
>> conflicts (and putting --with-bdeps=n in EMERGE_DEFAULT_OPTS would cause
>> undesirable --depclean behavior).
>>
>
> If I understand correctly, the end result of this is two --flags that
> combine in a (rather complicated) way to let the user control the
> default bdeps behavior of both "emerge --update" and "emerge --depclean"
> separately. I'll try to summarize my understanding:
>
>    I. emerge --update
>
>      I.a. Some people want to --update the build dependencies they have
>           installed for e.g. security purposes.
>
>      I.b. Others don't want build deps pulled in by "emerge --update",
>           because they're using binary packages or because it causes
>           conflicts in the resolver (llvm).
>
>   II. emerge --depclean
>
>     II.a. The default behavior is to not remove build-only dependencies
>           because, generally, they will just have to rebuilt again.
>
>     II.b. However, some people want to remove the build-only deps that
>           aren't strictly in use -- particularly if those build-only
>           deps are not being updated by emerge --update.
>
>
> To choose between those four options...
>
>   i.   --with-bdeps=n and --with-bdeps-auto=y gives you I.a. + II.b.

Incorrect.

These options give you I.b. + II.b. because --with-bdeps=n overrides
--with-bdeps-auto settings (the override is backward-compatible with
existing --with-bdeps usage).

Since I.a. + II.b. is a contradictory combination, there is no
combination of EMERGE_DEFAULT_OPTS that will give you I.a. + II.b.

Specifying --with-bdeps-auto=y has no effect, since that's the default.

>   ii.  --with-bdeps=n and --with-bdeps-auto=n gives you I.b. + II.b.

Correct.

Specifying --with-bdeps-auto=n has no effect, since --with-bdeps=n
overrides --with-bdeps-auto settings (the override is
backward-compatible with existing --with-bdeps usage).

>   iii. --with-bdeps=y and --with-bdeps-auto=y gives you I.a. + II.a.

Correct.

Specifying --with-bdeps-auto=y has no effect for 2 reasons:

* --with-bdeps-auto=y is the default
* --with-bdeps=y overrides --with-bdeps-auto settings (the override is
backward-compatible with existing --with-bdeps usage).

>   iv.  --with-bdeps=y and --with-bdeps-auto=n gives you I.a. + II.a.

Correct.

Specifying --with-bdeps-auto=n has no effect, since --with-bdeps=y
overrides --with-bdeps-auto settings (the override is
backward-compatible with existing --with-bdeps usage).

> That only gets you three out of the four options. You have to read the
> fine print to get the other:
>
>   v.   passing no flags explicitly gives you I.b. and II.a.

Incorrect.

Since --with-bdeps-auto=y is the the default setting, you get I.a. +
II.a. unless --usepkg is enabled. If --usepkg is enabled, you get I.b. +
II.a., which is backward-compatible with existing --usepkg usage.

> If there's going to be two flags, can't we do better? Why not just name
> the flags after what we want them to do:
>
>   --update-bdeps=<y|n> (default: y)
>
>   --clean-bdeps=<y|n>  (default: n)

The --with-bdeps-auto option results in desirable behavior by default,
and it's also backward compatible with existing --with-bdeps and
--usepkg usage. It just does the right thing, minimizing the impact to
existing emerge usage.

There some problems with --update-bdeps/--clean-bdeps:

* The program logic will be more complicated, since --with-bdeps will
have to override both options for backward-compatibility with existing
--with-bdeps usage.

* The meaning of --clean-bdeps is confusing. Does --clean-bdeps=y mean
to clean build time deps, or does it mean to pull build time deps into
the dependency graph for removal operations?

> With those two options, it's easy to tell portage exactly what you want.
> If I don't like the defaults, I can turn one of them off without
> affecting the other.

No, there are problems, as described above.

> But what about the --usepkg magic? I think the workaround can be left
> as-is. When --usepkg is enabled, switch the default for --update-bdeps
> to "n" unless it is explicitly set.

That would work, but introducing 2 new options is no really appealing,
because it will lead to more complicated logic that will be more
difficult to explain and for people to comprehend. I really don't want
to spend time documenting the interactions between --with-bdeps,
--update-bdes, and --clean-bdeps, and then get a ton of frequently asked
questions from people having difficulty understanding it.

Overall, I think the --with-bdeps-auto approach seems simpler and easier
to explain. I think you would have completely understood it if you had
read through the man page updates.

> Food for thought. Anyway, thanks for working on this.
-- 
Thanks,
Zac