I have installed the latest ~amd64 poppler. Now on "emerge -uDN world", portage forces me to downgrade poppler. Portage describes the reason for the poppler downgrade as follows: app-text/poppler:0 (app-text/poppler-0.24.5::gentoo, installed) pulled in by app-text/poppler:0/44=[xpdf-headers(+)] required by (dev-tex/luatex-0.76.0::gentoo, installed) >=app-text/poppler-0.20:0/44=[cairo] required by (app-text/evince-3.8.3::gentoo, installed) app-text/poppler:0/44=[cxx,jpeg,lcms,tiff,xpdf-headers(+)] required by (net-print/cups-filters-1.0.43-r1::gentoo, installed) app-text/poppler:0/44=[qt4] required by (app-office/texstudio-2.6.6::gentoo, installed) (and 3 more with the same problems) (app-text/poppler-0.24.3::gentoo, ebuild scheduled for merge) pulled in by >=app-text/poppler-0.16:0/43=[xpdf-headers(+),cxx] required by (app-office/libreoffice-4.1.4.2::gentoo, installed) Now it seems like the poppler downgrade is due to libreoffice, but neither "emerge -p libreoffice", "equery d poppler", nor a look at libreoffice's ebuild would confirm that. In particular, "emerge -p libreoffice" does _not_ want to downgrade poppler which means that libreoffice is not the cause. In particular, the output of "equery d poppler" is as follows: # equery d poppler * These packages depend on poppler: app-misc/tracker-0.16.4 (pdf ? >=app-text/poppler-0.16[cairo,utils]) app-office/libreoffice-4.1.4.2 (>=app-text/poppler-0.16[xpdf-headers(+),cxx]) app-office/texstudio-2.6.6 (app-text/poppler[qt4]) app-text/dvipdfmx-20110311 (>=app-text/poppler-0.12.3-r3) app-text/evince-3.8.3 (>=app-text/poppler-0.20[cairo]) app-text/mate-document-viewer-1.6.1-r1 (>=app-text/poppler-0.14[cairo]) app-text/texlive-core-2013-r1 (>=app-text/poppler-0.12.3-r3) dev-tex/luatex-0.76.0 (app-text/poppler[xpdf-headers(+)]) media-gfx/gimp-2.8.10 (pdf ? >=app-text/poppler-0.12.4[cairo]) media-gfx/inkscape-0.48.4-r1 (>=app-text/poppler-0.12.3-r3[cairo,xpdf-headers(+)]) net-print/cups-1.7.0-r1 (app-text/poppler[utils]) net-print/cups-filters-1.0.43-r1 (app-text/poppler[cxx,jpeg?,lcms,tiff?,xpdf-headers(+)]) None of these packages seem to force a poppler downgrade. And I can't figure out what the source of the problem is. I also tried "emerge -uDN worl -pt" but it lists libreoffice as a parent of poppler in the tree. I believe it is a bug, that portage doesn't list the cause for the downgrade in the output. Instead, it lists libreoffice, which seems to be a random package that happens to depend on poppler. Reproducible: Always
I'm using portage 2.2.8
Please post the merge list (use --verbose).
(In reply to Sebastian Luther (few) from comment #2) > Please post the merge list (use --verbose). Don't bother. The problem is that libreoffice needs to be rebuild because of a poppler sub-slot change. The question is why this doesn't happen. Try with a higher --backtracking value and if that doesn't help, attach the full output with --debug added.
(In reply to Sebastian Luther (few) from comment #3) > (In reply to Sebastian Luther (few) from comment #2) > > Please post the merge list (use --verbose). > > Don't bother. The problem is that libreoffice needs to be rebuild because of > a poppler sub-slot change. The question is why this doesn't happen. That is correct. I didn't rebuild libreoffice after I upgraded poppler. I wonder: by which internal logic does portage think that it's a good idea to install the old poppler version that the currently installed libreoffice binaries are linked against. I mean, the version of libreoffice that is currently installed does not have a dependency on the old version poppler. I mean, I know that portage does consider these runtime-dependencies when doing a --depclean. But why does it consider this runtime-dependency when doing an "emerge -uDN world"? > Try with a higher --backtracking value and if that doesn't help, attach the > full output with --debug added. I will have to undo some changes I just did, because the issue suddenly disappeared. If the issue comes up again, I will try the solution you suggested.
(In reply to Sven from comment #4) > (In reply to Sebastian Luther (few) from comment #3) > > (In reply to Sebastian Luther (few) from comment #2) > > > Please post the merge list (use --verbose). > > > > Don't bother. The problem is that libreoffice needs to be rebuild because of > > a poppler sub-slot change. The question is why this doesn't happen. > > That is correct. I didn't rebuild libreoffice after I upgraded poppler. I > wonder: by which internal logic does portage think that it's a good idea to > install the old poppler version that the currently installed libreoffice > binaries are linked against. It is supposed to reinstall libreoffice. There is either a bug in portage or a configuration problem in your system. > I mean, the version of libreoffice that is > currently installed does not have a dependency on the old version poppler. It does have a dependency on the old sub-slot. > I mean, I know that portage does consider these runtime-dependencies when > doing a --depclean. But why does it consider this runtime-dependency when > doing an "emerge -uDN world"? Because the package otherwise doesn't work. People generally want things in their world file to work and if that package is a buildtime dependency of something else, then it needs to work too, or the build will fail.
I created a test case from what you posted so far and that behaves as expected. -> NEEDINFO
I increased the backtracking value to 20, then portage got it right: # emerge -uDN world -p --backtrack=20 These are the packages that would be merged, in order: Calculating dependencies... done! The following packages are causing rebuilds: (dev-lang/perl-5.18.1::gentoo, ebuild scheduled for merge) causes rebuilds for: (net-print/cups-filters-1.0.43-r1::gentoo, ebuild scheduled for merge) (dev-perl/WWW-RobotRules-6.10.0-r1::gentoo, ebuild scheduled for merge) (dev-vcs/subversion-1.8.5::gentoo, ebuild scheduled for merge) (dev-vcs/git-1.8.5.3::gentoo, ebuild scheduled for merge) [ebuild r U #] dev-lang/perl-5.18.1 [5.16.3] [ebuild N ] perl-core/MIME-Base64-3.130.0 [ebuild N ] perl-core/JSON-PP-2.272.0 [ebuild N ] perl-core/Test-Simple-0.980.0 [ebuild N ] perl-core/File-Temp-0.220.0 [ebuild N ] perl-core/ExtUtils-Command-1.170.0 [ebuild N ] perl-core/Package-Constants-0.20.0 [ebuild N ] perl-core/Perl-OSType-1.2.0 USE="{-test}" [ebuild N ] perl-core/Locale-Maketext-Simple-0.210.0 [ebuild N ~] virtual/perl-Exporter-5.680.0 [ebuild N ] perl-core/Time-HiRes-1.972.500 [ebuild N ] perl-core/PodParser-1.510.0 [ebuild N ] perl-core/Pod-Escapes-1.40.0 [ebuild N ] virtual/perl-PodParser-1.510.0-r1 [ebuild N ] perl-core/digest-base-1.170.0 [ebuild N ] perl-core/Getopt-Long-2.380.0 [ebuild rR ] dev-perl/WWW-RobotRules-6.10.0-r1 [ebuild N ] perl-core/IO-Zlib-1.100.0 [ebuild N ~] dev-perl/autovivification-0.120.0 [ebuild rR ~] net-print/cups-filters-1.0.43-r1 [ebuild U ~] dev-tex/biber-1.8 [1.7-r1] [ebuild rR ~] dev-vcs/subversion-1.8.5 [ebuild rR ~] dev-vcs/git-1.8.5.3 [ebuild rR ~] app-office/libreoffice-4.1.4.2 Merging perl 5.18 was not intended. I know how to fix that. But obviously that caused portage not to re-emerge libreoffice for some reason.
With backtracking default (I think the value is 10), portage wants to perform the following actions: # emerge -uDN world -p These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] media-libs/jpeg-8d USE="-static-libs" [ebuild UD ] virtual/jpeg-0 [0-r2] [ebuild UD ] media-libs/tiff-4.0.3-r4 [4.0.3-r5] [ebuild UD ] media-libs/freetype-2.4.11 [2.4.11-r2] [ebuild U #] dev-lang/perl-5.18.1 [5.16.3] [ebuild N ~] virtual/perl-Exporter-5.680.0 [ebuild N ~] dev-perl/autovivification-0.120.0 [ebuild UD ] app-text/poppler-0.24.3 [0.24.5] [ebuild U ~] dev-tex/biber-1.8 [1.7-r1] [blocks B ] media-libs/jpeg:0 ("media-libs/jpeg:0" is blocking media-libs/libjpeg-turbo-1.3.0-r2) !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: Note that all the downgrades are conflicts.
Portage basically always reports the same reason for everything. It's really annoying, as I tend to keep my portage.keywords file organized. Consider the following example that just happened to me: I have firefox and networkmanager keyworded. I have firefox 32 installed and the latest networkmanager. Due to an emerge --sync, firefox 33 pops up in my portage tree. Now, emerge -uDN world -p showed me that I need to keyword =dev-libs/nss-3.17.2 because networkmanager requires it. But networkmanager wasn't even in the list of packages that would be merged (I guess the ebuild of networkmanager could have changed due to the sync). And in fact, networkmanager's ebuild doesn't require any dev-libs/nss newer than I have installed. It's firefox that requires it.
(In reply to Sven from comment #9) > I have firefox and networkmanager keyworded. I have firefox 32 installed and > the latest networkmanager. Due to an emerge --sync, firefox 33 pops up in my > portage tree. Now, emerge -uDN world -p showed me that I need to keyword > =dev-libs/nss-3.17.2 because networkmanager requires it. But networkmanager > wasn't even in the list of packages that would be merged (I guess the ebuild > of networkmanager could have changed due to the sync). That's emerge --dynamic-deps in action. > And in fact, > networkmanager's ebuild doesn't require any dev-libs/nss newer than I have > installed. It's firefox that requires it. That's bug 419381 (or closely related).
(In reply to Zac Medico from comment #10) > That's bug 419381 (or closely related). Sounds very much like this is the problem I'm seeing.
