* /usr/include/gdk-pixbuf-2.0/gdk-pixbuf-xlib/gdk-pixbuf-xlib.h * /usr/lib64/libgdk_pixbuf_xlib-2.0.so * /usr/lib64/libgdk_pixbuf_xlib-2.0.so.0 * * Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * x11-libs/gdk-pixbuf-xlib-2.40.2:0::gentoo * /usr/include/gdk-pixbuf-2.0/gdk-pixbuf-xlib/gdk-pixbuf-xlib.h * /usr/include/gdk-pixbuf-2.0/gdk-pixbuf-xlib/gdk-pixbuf-xlibrgb.h * /usr/lib64/libgdk_pixbuf_xlib-2.0.so * /usr/lib64/libgdk_pixbuf_xlib-2.0.so.0 * /usr/lib64/pkgconfig/gdk-pixbuf-xlib-2.0.pc * * Package 'x11-libs/gdk-pixbuf-2.40.0' NOT merged due to file ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_desktop_plasma_systemd-20201109-205253 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-8.3.1 [2] x86_64-pc-linux-gnu-10.2.0 * clang version 11.0.0 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/11/bin /usr/lib/llvm/11 11.0.0 Available Python interpreters, in order of preference: [1] python3.7 [2] python3.9 (fallback) [3] python3.8 (fallback) [4] python2.7 (fallback) [5] pypy3 (fallback) Available Ruby profiles: [1] ruby25 (with Rubygems) [2] ruby26 (with Rubygems) [3] ruby27 (with Rubygems) * Available Rust versions: [1] rust-1.47.0 * The following VMs are available for generation-2: *) AdoptOpenJDK 8.272_p10 [openjdk-bin-8] Available Java Virtual Machines: [1] openjdk-bin-8 system-vm The Glorious Glasgow Haskell Compilation System, version 8.8.4 timestamp(s) of HEAD at this tinderbox image: /var/db/repos/gentoo Sun Nov 15 05:42:19 PM UTC 2020 emerge -qpvO x11-libs/gdk-pixbuf [ebuild R ] x11-libs/gdk-pixbuf-2.42.0 USE="introspection jpeg tiff -gtk-doc" ABI_X86="(64) -32 (-x32)"
Created attachment 671545 [details] emerge-info.txt
Created attachment 671548 [details] emerge-history.txt
Created attachment 671551 [details] etc.portage.tbz2
Created attachment 671554 [details] logs.tbz2
Created attachment 671557 [details] x11-libs:gdk-pixbuf-2.40.0:20201115-181153.log
How did you manage to get that collission? The package explicitly R/DEPENDs on >=x11-libs/gdk-pixbuf-2.42.0
My suspicion is that /usr/lib64/libgdk_pixbuf_xlib-2.0.so and friends are left-over preserved-libs. E.g., (1) gdk-pixbuf-2.40[X] was installed for some dependency which needed libgdk_pixbuf_xlib-2.0.so; (2) gdk-pixbuf was updated to 2.42, and preserved-libs kept libgdk_pixbuf_xlib-2.0.so around; (3) gdk-pixbuf-xlib is installed, causing the file collisions. I don't think a blocker dep would help here, since my hypothesis is that this is due to preserved-libs. Zac... any ideas how or if portage could handle this differently?
The collision involves *.h and *.pc files as well as libraries, which suggests that it was caused by an interrupted merge. There's an 'emaint --check merges' command that will check for interrupted merges. The 'emaint --fix merges' command will remove the /var/db/pkg/*/*-MERGING-* directories, log them in /var/lib/portage/failed-merges, and will invoke emerge to rebuild the corresponding packages with FEATURES="-collision-protect -protect-owned". Note that collision-protect is not enabled by default, which mitigates the problem. By default, FEATURES="protect-owned" is enabled so that users can ignore collisions with orphaned files.
Actually, the log shows that x11-libs/gdk-pixbuf-xlib-2.40.2:0::gentoo was "normally" installed when the collision occurred. This indicates that the x11-libs/gdk-pixbuf-xlib-2.40.2:0::gentoo package would likely be removed by `emerge --depclean`, which is one of the reasons that we recommend to run `emerge --depclean` after @world updates.
Note that emerge would resolve this collision by automatic uninstall of x11-libs/gdk-pixbuf-xlib if we put a soft blocker like RDEPEND+=" !x11-libs/gdk-pixbuf-xlib" in gdk-pixbuf-2.40.0.ebuild.
Created attachment 671572 [details] emerge.log.xz for completeness the whole emerge.log
(In reply to Zac Medico from comment #9) > which is one of the reasons that we recommend to run > `emerge --depclean` after @world updates. *If* the tinderbox would install packages in the same (yes, randomized) order as a @world would do in the same situation - then no "--deplcean" would be scheduled by a common user, or?
(In reply to Toralf Förster from comment #12) > (In reply to Zac Medico from comment #9) > > which is one of the reasons that we recommend to run > > `emerge --depclean` after @world updates. > > *If* the tinderbox would install packages in the same (yes, randomized) > order as a @world would do in the same situation - then no "--deplcean" > would be scheduled by a common user, or? You'd never get into this particular state with a normal world update unless you had first upgraded to x11-libs/gdk-pixbuf-2.42.0 and x11-libs/gdk-pixbuf-xlib-2.40.2 and then masked them for some reason. In that case, we probably wouldn't expect the user to run emerge --depclean until after the next world update, and a blocker like RDEPEND+=" !x11-libs/gdk-pixbuf-xlib" in gdk-pixbuf-2.40.0.ebuild would resolve the collision automatically.