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?
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
> If of interest I can preserve a snapshot of the state the next time this
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:
This is in the master branch:
Fixed in portage-2.3.5.