Summary: | x11-libs/gdk-pixbuf-2.40.0 : file collision with x11-libs/gdk-pixbuf-xlib-2.40.2 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Toralf Förster <toralf> |
Component: | Current packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | dev-portage, polynomial-c |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
emerge-info.txt
emerge-history.txt etc.portage.tbz2 logs.tbz2 x11-libs:gdk-pixbuf-2.40.0:20201115-181153.log emerge.log.xz |
Description
Toralf Förster
2020-11-15 18:39:45 UTC
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. |