* Searching all installed packages for file collisions...
* Press Ctrl-C to Stop
* 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)
 x86_64-pc-linux-gnu-10.2.0 *
clang version 11.0.0
Thread model: posix
Available Python interpreters, in order of preference:
 python3.9 (fallback)
 python3.8 (fallback)
 python2.7 (fallback)
 pypy3 (fallback)
Available Ruby profiles:
 ruby25 (with Rubygems)
 ruby26 (with Rubygems)
 ruby27 (with Rubygems) *
Available Rust versions:
 rust-1.47.0 *
The following VMs are available for generation-2:
*) AdoptOpenJDK 8.272_p10 [openjdk-bin-8]
Available Java Virtual Machines:
 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]
Created attachment 671548 [details]
Created attachment 671551 [details]
Created attachment 671554 [details]
Created attachment 671557 [details]
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]
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.