On 06/22/2016 03:57 PM, Dan Douglas wrote: > On 06/22/2016 12:31 PM, Neil Bothwick wrote: >> On Wed, 22 Jun 2016 08:39:59 -0500, Dan Douglas wrote: >>> --keep-going is in EMERGE_DEFAULT_OPTS so the problem is only when >>> that fails for whatever reason, --resume (with or without >>> --skip-first) always fails too. >> On 06/22/2016 12:31 PM, Neil Bothwick wrote: >> That makes sense, --keep-going has already made sure that all updates >> that are not dependant on the failing one have emerged, so there's >> nothing left to emerge until you fix the broken package. > > > That's what it should do but it clearly doesn't quite work that way. > It's easy to prove it's broken by finding any package on the resume list > that can merge on its own without pulling in a previously failed package. > > I've had completely up-to-date systems where no possible failure could > result in an unsatisfied dependency and portage refuses to resume an > `emerge -e @world` with hundreds of possible packages on the resume list > that would work in isolation. That's the problem. > >
Often, the issue in these cases is that there is some broken dependency already present on the system (for some value of "broken"). This may be a package that is not required by anything (so --depclean would remove it) is now broken because it requires something that isn't installed. It may also be a package that is only required as a build dependency of something, if you do not have '--with-bdeps=y' in your EMERGE_DEFAULT_OPTS. Unfortunately, it is difficult to get portage to explain what it thinks is broken in these cases. If trying to do a `emerge -pvte @world` shows packages that would be updated, newly installed, or rebuilt, when your normal @world update would show nothing, this may be part of the problem. -- Jonathan Callen
signature.asc
Description: OpenPGP digital signature
