Michael Orlitzky posted on Sun, 05 Mar 2017 14:44:58 -0500 as excerpted:
> On 03/05/2017 02:12 PM, Zac Medico wrote:
>>
>> Incorrect.
>>
>> ...
>>
>> Incorrect.
>>
>>
> I see my mistakes, but maintain that this is confusing =)
For the record, I think it's /somewhat/ confusing too, and would
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 o
On 03/05/2017 02:12 PM, Zac Medico wrote:
>
> Incorrect.
>
> ...
>
> Incorrect.
>
I see my mistakes, but maintain that this is confusing =)
>
> The --with-bdeps-auto option results in desirable behavior by default,
> and it's also backward compatible with existing --with-bdeps and
> --usepk
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= 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 --w
On 03/05/2017 03:40 AM, Zac Medico wrote:
>
> A new --with-bdeps-auto= 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 inst
It's useful to automatically enable --with-bdeps so that @world updates
will update all packages that are not eligible for removal by
emerge --depclean. However, many users of binary packages do not want
unnecessary build time dependencies installed, therefore do not
auto-enable --with-bdeps for in
