'emerge -v --update --newuse --deep --with-bdeps=y --backtrack=30 @world' fails with: root@impala:/root(15)# emerge -v --update --newuse --deep --with-bdeps=y --backtrack=30 @world These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] app-text/poppler-0.34.0:0/53::gentoo [0.33.0-r1:0/52::gentoo] USE="cairo curl cxx doc introspection jpeg jpeg2k lcms png qt4 qt5 tiff utils -cjk -debug" 1,578 KiB [ebuild U ] dev-python/pycups-1.9.73::gentoo [1.9.72::gentoo] USE="doc examples" PYTHON_TARGETS="python2_7 python3_3 -pypy -python3_4" 52 KiB [ebuild UD ] sci-mathematics/octave-3.8.2:0/3.8.2::gentoo [4.0.0:0/4.0.0::gentoo] USE="X curl doc fftw glpk gnuplot gui hdf5 imagemagick java opengl postscript qhull qrupdate readline sparse zlib -jit -static-libs" 17,417 KiB [ebuild U ] media-tv/xawtv-3.95-r3::gentoo [3.95-r2::x-portage] USE="X alsa dv motif nls opengl quicktime xext xv zvbi -aalib -lirc (-mmx%)" CPU_FLAGS_X86="(-mmx)" 0 KiB Total: 4 packages (3 upgrades, 1 downgrade), Size of downloads: 19,046 KiB !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: app-text/poppler:0 (app-text/poppler-0.34.0:0/53::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) (app-text/poppler-0.33.0-r1:0/52::gentoo, installed) pulled in by >=app-text/poppler-0.12.3-r3:0/52= required by (app-text/texlive-core-2014-r4:0/0::gentoo, installed) ^^^^^^ (and 12 more with the same problem)
Messages like that confuse me. The first part states "pulled in by no parents which are not satisfied by other packages in this slot" - which indicates that there are no package dependencies requiring the upgrade (ie the currently installed package satisfies all dependencies). So should a suitable resolution not be for Portage to just skip the upgrade of the package.
> So should a > suitable resolution not be for Portage to just skip the upgrade of the > package. I don't think that should be necessary. I've also had this bug happen to me, and rather than forcing the newer poppler to be skipped, it seems that it can be made to build if all the blocking packages are also rebuilt. In this case, explicitly adding app-text/texlive-core to the list of packages to build will result in a similar warning, but with another blocker listed (and now only 11 more with the same problem). After 11 more iterations of this, everything will have been listed, and so portage will finally consent to do the build. If portage knows these dependencies, then surely it should be automatically arranging to rebuild them. Or, failing that, is there any way to get it to display the whole list of packages in one go, rather than just one of them together with an "and n more with the same problem" message?
Can you try with an updated tree? Some weeks ago there were some missed texlive stabilizations that caused some blockers thanks
