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

[Zac Medico]

On 03/05/2017 11:44 AM, Michael Orlitzky wrote:
> On 03/05/2017 02:12 PM, Zac Medico wrote:
>>
>> Incorrect.
>>
>> ...
>>
>> Incorrect.
>>
>
> I see my mistakes, but maintain that this is confusing =)

It could be worse, and I think it's questionable that we could do any
better, given the nature of the problem.

>> 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.
>
> I was hoping that since nothing breaks with --update-bdeps=y and
> --clean-bdeps=n (the new defaults), we could just disable --with-bdeps
> immediately and emit a warning when it's given.

Breaking backward compatibility is too disruptive, unless we allow for a
transition period where --with-bdeps is deprecated.

>> 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.
>
> Not applicable if --with-bdeps goes away.

We don't have a justification to break compatibility without a
transition period.

>> * 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?
>
> --clean-bdeps means clean the bdeps.

It's confusing to have an option with inverted meaning relative to
--with-bdeps. Cleaning the bdeps is a consequence of excluding them from
the dependency graph, not an action in itself. --clean-bdeps sounds like
an action.

> I totally agree that the worst option of all is to keep --with-bdeps AND
> introduce the other two.
-- 
Thanks,
Zac