Bug 598444 – Make --with-bdeps=y always default (also for installation actions)

• Product: Portage Development
• Status: RESOLVED FIXED

[Description Andreas K. Hüttel 2016-10-29 13:43:02 UTC]

I suspect that bug 592880 and friends are triggered by --with-bdeps=n

At least in my case I have never seen such problems myself, but I'm also setting --with-bdeps=y as default on all my machines. Others seem to have the same suspicion. 

With that in mind, could we maybe make this the default in a future portage version?

[Comment 1 Andreas K. Hüttel 2016-10-29 14:23:39 UTC]

As a clarification, I know this is only a workaround which hides the real problem. I just would like to avoid the hordes of angry users shouting about Perl upgrades... :o) 

Identifying and fixing the underlying bug would be better, but also seems complex and challenging.

[Comment 2 Zac Medico 2016-10-29 19:50:51 UTC]

I think we should do this, except the default should be something like --with-bdeps-if-not-usepkg, so that it won't interfere with people's existing binary package workflows.

IMO, the interaction with --depclean (see bug 266861) is enough reason to enable some form of --with-bdeps by default.

[Comment 3 Pacho Ramos 2017-01-16 08:57:35 UTC]

(In reply to Zac Medico from comment #2)
> I think we should do this, except the default should be something like
> --with-bdeps-if-not-usepkg, so that it won't interfere with people's
> existing binary package workflows.
> 
> IMO, the interaction with --depclean (see bug 266861) is enough reason to
> enable some form of --with-bdeps by default.

I just hit again this with depclean and reminded that this wasn't enabled finally, could this be done for the next portage release please? 

Thanks!

[Comment 4 Zac Medico 2017-01-19 06:31:20 UTC]

Rather than introduce a new option, I think we can just enable --with-bdeps automatically when it makes sense, as long as the user has no forced it off via --with-bdeps=n. We already enable some other options automatically when conflicting options have not been specified, like --binpkg-respect-use and --rebuilt-binaries, so I think we can do something similar for --with-bdeps.

[Comment 5 Matthias Maier 2017-01-28 04:28:06 UTC]

I have run into resolver issues with --with-bdeps=n in my minimal stage-3 lxc containers a couple of times (they run --with-bdeps=n to spot DEPEND problems).

If of interest I can preserve a snapshot of the state the next time this happens.

[Comment 6 Zac Medico 2017-01-28 07:48:59 UTC]

(In reply to Matthias Maier from comment #5)
> I have run into resolver issues with --with-bdeps=n in my minimal stage-3
> lxc containers a couple of times (they run --with-bdeps=n to spot DEPEND
> problems).
> 
> If of interest I can preserve a snapshot of the state the next time this
> happens.

Yes, if you have something that looks like a resolver issue then please file a bug and we'll investigate it. It's always helpful to have a snapshot if the state available.

[Comment 7 Zac Medico 2017-03-04 09:45:47 UTC]

Patch posted for review:

https://archives.gentoo.org/gentoo-portage-dev/message/2281db73ccbb9459e3eec8b393c975cc
https://github.com/gentoo/portage/pull/132

[Comment 8 Zac Medico 2017-03-08 19:22:37 UTC]

This is in the master branch:

https://gitweb.gentoo.org/proj/portage.git/commit/?id=852c729bdef3d4c2e2d459a43dc21f0a05dfa2ba

[Comment 9 Zac Medico 2017-05-20 18:22:19 UTC]

Fixed in portage-2.3.5.