| Summary: | app-portage/gentoolkit: revdep-rebuild doesn't handle USE=multislot | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Ben Longbons <b.r.longbons> |
| Component: | [OLD] Core system | Assignee: | Portage Tools Team <tools-portage> |
| Status: | RESOLVED INVALID | ||
| Severity: | blocker | CC: | alexander, b.r.longbons |
| Priority: | Highest | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=507808 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
nothing to be done on the toolchain side. i'll leave it to the revdep-rebuild guys to decide what to do here (maybe just dupe to bug 174407). Since your bug report doesn't include any output from revdep-rebuild, it is not clear to me what the problem is. Can you please run either of the following commands (depending on what is currently on your system) and paste the output into the bug? revdep-rebuild.sh --library /usr/lib64/libmpc.so.2 --pretend revdep-rebuild.sh --library /usr/lib64/libmpc.so.3 --pretend I suspect that a fix will require dynamic slot support from the package managers. (In reply to comment #2) $ revdep-rebuild.sh --library /usr/lib64/libmpc.so.3 --pretend * Configuring search environment for revdep-rebuild * Checking reverse dependencies * Packages containing binaries and libraries using /usr/lib64/libmpc.so.3 * will be emerged. * Collecting system binaries and libraries * Generated new 1_files.rr * Checking dynamic linking [ 95% ] * found /usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.4/cc1 * found /usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.4/cc1plus * found /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/cc1 * found /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/cc1plus * found /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/lto1 * found /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.1/cc1 * found /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.1/cc1plus * found /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.1/lto1 * found /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.2/cc1 * found /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.2/cc1plus * found /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.2/f951 * found /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.2/lto1 * found /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/cc1 * found /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/cc1plus * found /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/lto1 * found /usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.0/cc1 [ 96% ] * found /usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.0/cc1plus * found /usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.0/lto1 * found /usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.1/cc1 * found /usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.1/cc1plus * found /usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.1/lto1 [ 100% ] * Generated new 3_broken.rr * Assigning files to packages * /usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.4/cc1 -> sys-devel/gcc * /usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.4/cc1plus -> sys-devel/gcc * /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/cc1 -> sys-devel/gcc * /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/cc1plus -> sys-devel/gcc * /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/lto1 -> sys-devel/gcc * /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.1/cc1 -> sys-devel/gcc * /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.1/cc1plus -> sys-devel/gcc * /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.1/lto1 -> sys-devel/gcc * /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.2/cc1 -> sys-devel/gcc * /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.2/cc1plus -> sys-devel/gcc * /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.2/f951 -> sys-devel/gcc * /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.2/lto1 -> sys-devel/gcc * /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/cc1 -> sys-devel/gcc * /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/cc1plus -> sys-devel/gcc * /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/lto1 -> sys-devel/gcc * /usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.0/cc1 -> sys-devel/gcc * /usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.0/cc1plus -> sys-devel/gcc * /usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.0/lto1 -> sys-devel/gcc * /usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.1/cc1 -> sys-devel/gcc * /usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.1/cc1plus -> sys-devel/gcc * /usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.1/lto1 -> sys-devel/gcc * Generated new 4_raw.rr and 4_owners.rr * Cleaning list of packages to rebuild * Generated new 4_pkgs.rr * Assigning packages to ebuilds * Generated new 4_ebuilds.rr * Evaluating package order * Generated new 5_order.rr * All prepared. Starting rebuild emerge --complete-graph=y --oneshot -v --keep-going --quiet-build y --with-bdeps y --pretend sys-devel/gcc:4.5 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sys-devel/gcc-4.5.4 USE="cxx doc gtk mudflap (multilib) nptl openmp (-altivec) -bootstrap -build (-fixed-point) -fortran -gcj -graphite (-hardened) (-libssp) -lto -multislot -nls -nocxx -nopie -nossp -objc -objc++ -objc-gc -test -vanilla" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB * Now you can remove -p (or --pretend) from arguments and re-run revdep-rebuild. > I suspect that a fix will require dynamic slot support from the package > managers. True, although a minor improvement would be to change the exit status of revdep-rebuild to indicate failure if *any* step fails. Further testing shows that the fact that I set multislot for a small range in package.use is irrelevant. emerge fails to find candidates for the slots even when it is set in make.conf I guess the only workaround without giving up multislot entirely, is to disable it explicitly for the highest unmasked :4.6, so at least I won't lose my system compiler again. I guess I could try to implement the separate gcc-multislot package in my overlay, which although it was rejected after my suggestion in the "feature request" bug, would actually leave working system, unlike what we have now. If I sound kind of upset here it's because maybe I am upset, in that no one seems to be taking this seriously. It's one thing to have feature request, it's quite another for the tree you ship to break the system compiler. It was sheer laziness that I had an older compiler non-multislotted, and I have just demonstrated that that condition is not necessary to trigger the bug. I have the same issue. This is probably not related to multislot.
$ sudo revdep-rebuild -i -- -1av
* Configuring search environment for revdep-rebuild
* Checking reverse dependencies
* Packages containing binaries and libraries broken by a package update
* will be emerged.
* Collecting system binaries and libraries
* Generated new 1_files.rr
* Collecting complete LD_LIBRARY_PATH
* Generated new 2_ldpath.rr
* Checking dynamic linking consistency
[ 68% ] * broken /usr/lib64/libCEGUIOpenGLRenderer.so.0.1.0 (requires libGLEW.so.1.6)
[ 100% ]
* Generated new 3_broken.rr
* Assigning files to packages
* /usr/lib64/libCEGUIOpenGLRenderer.so.0.1.0 -> dev-games/cegui
* Generated new 4_raw.rr and 4_owners.rr
* Cleaning list of packages to rebuild
* Generated new 4_pkgs.rr
* Assigning packages to ebuilds
* Generated new 4_ebuilds.rr
* Evaluating package order
* Generated new 5_order.rr
* All prepared. Starting rebuild
emerge --complete-graph=y --oneshot --with-bdeps y -1av dev-games/cegui:0
..........
These are the packages that would be merged, in order:
Calculating dependencies /
!!! Problem resolving dependencies for dev-games/cegui:0
... done!
[ebuild U ] dev-games/cegui-0.7.7-r1 [0.6.2b] USE="examples gtk%* opengl pcre%* truetype%* xml* -bidi% -debug -devil -doc -expat -irrlicht -lua -ogre%
-static-libs% -tinyxml% -xerces-c -zip% (-directfb%)" 8,962 kB
Total: 1 package (1 upgrade), Size of downloads: 8,962 kB
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:
dev-games/cegui:0
(dev-games/cegui-0.7.7-r1::gentoo, ebuild scheduled for merge) pulled in by
(no parents that aren't satisfied by other packages in this slot)
(dev-games/cegui-0.6.2b::gentoo, installed) pulled in by
=dev-games/cegui-0.6*[opengl] required by (app-emulation/spice-0.11.3::gentoo, installed)
(In reply to comment #5) It seems my issue is not caused by revdep-rebuild. So please ignore my comments. I'm sorry. :) USE=multislot is a severe QA violation and is masked for some time now. There's no reason to expect people to support it in any way. |
Portage is schizophrenic and does not always detect the fact that multislot should change the SLOT= of the package. The most severe effect of this on my system was that copy-pasting the revdep-rebuild && rm line from the dev-libs/mpc upgrade left me without a working gcc, since revdep-rebuild had to give up on finding something for the :${CHOST}-4.6.2 SLOT, and returned an exit code of 0, interpreted as success. Fortunately, I had disabled multislot for older versions of gcc (and even older versions seem to be statically linked) Even discounting the disastrous change from ${CHOST}-x.y.z to just x.y.z, searching for the slot does not work: Reproducible: Always Steps to Reproduce: $ USE=multislot emerge -p =sys-devel/gcc-4.3.{4,5} Actual Results: These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild NS ] sys-devel/gcc-4.3.4 [4.5.3-r2, 4.6.3] USE="cxx mudflap (multilib) multislot nptl openmp (-altivec) -bootstrap -build -doc (-fixed-point) -fortran -gcj -gtk (-hardened) (-libssp) -nls -nocxx -nopie -nossp -objc -objc++ -objc-gc -test -vanilla" [ebuild NS ] sys-devel/gcc-4.3.5 [4.5.3-r2, 4.6.3] USE="cxx mudflap (multilib) multislot nptl openmp (-altivec) -bootstrap -build -doc (-fixed-point) -fortran -gcj -gtk (-hardened) (-libssp) -nls -nocxx -nopie -nossp -objc -objc++ -objc-gc -test -vanilla" !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: sys-devel/gcc:4.3 (sys-devel/gcc-4.3.4::gentoo, ebuild scheduled for merge) pulled in by =sys-devel/gcc-4.3.4 (sys-devel/gcc-4.3.5::gentoo, ebuild scheduled for merge) pulled in by =sys-devel/gcc-4.3.5 Expected Results: multiple slots can be installed In /etc/portage/package.use, I have >=sys-devel/gcc-4.6 multislot