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?
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.
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.
(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!
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.
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.
(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.
Patch posted for review: https://archives.gentoo.org/gentoo-portage-dev/message/2281db73ccbb9459e3eec8b393c975cc https://github.com/gentoo/portage/pull/132
This is in the master branch: https://gitweb.gentoo.org/proj/portage.git/commit/?id=852c729bdef3d4c2e2d459a43dc21f0a05dfa2ba
Fixed in portage-2.3.5.
