April 11, 2015

Tricks for resolving slot conflicts and blockers

Slot conflicts can be annoying. It's worse when an attempt to fix them leads to an even bigger mess. I hope this post helps you with some cases - and that portage will keep getting smarter about resolving them automatically.


It's mostly a transcript of commands and output snippets. Let's take a look:

# emerge -uDNa world

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

dev-libs/icu:0

  (dev-libs/icu-54.1-r1:0/54a::gentoo, ebuild scheduled for merge) pulled in by
    (no parents that aren't satisfied by other packages in this slot)

  (dev-libs/icu-53.1:0/53::gentoo, installed) pulled in by
    >=dev-libs/icu-51.2-r1:0/53=[abi_x86_32(-)] required by (media-libs/harfbuzz-0.9.28:0/0.9.18::gentoo, installed)
                          ^^^^^^                                                                                                                      
    (and 3 more with the same problem)

dev-lang/perl:0

  (dev-lang/perl-5.20.1-r4:0/5.20::gentoo, ebuild scheduled for merge) pulled in by
    (no parents that aren't satisfied by other packages in this slot)

  (dev-lang/perl-5.18.2-r2:0/5.18::gentoo, installed) pulled in by
    dev-lang/perl:0/5.18=[-build(-)] required by (dev-perl/XML-Parser-2.410.0-r2:0/0::gentoo, installed)
                 ^^^^^^^^                                                                                                                
    (and 6 more with the same problem)

x11-base/xorg-server:0

  (x11-base/xorg-server-1.16.4:0/1.16.1::gentoo, ebuild scheduled for merge) pulled in by
    (no parents that aren't satisfied by other packages in this slot)

  (x11-base/xorg-server-1.15.0:0/1.15.0::gentoo, installed) pulled in by
    x11-base/xorg-server:0/1.15.0= required by (x11-drivers/xf86-video-vesa-2.3.3:0/0::gentoo, installed)
                        ^^^^^^^^^^                                                                                                        

!!! The ebuild selected to satisfy ">=media-libs/gst-plugins-bad-1.4.5:1.0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]" has unmet requirements.
- media-libs/gst-plugins-bad-1.4.5::gentoo USE="X gles2 introspection nls opengl orc -egl -vnc -wayland"

  The following REQUIRED_USE flag constraints are unsatisfied:
    gles2? ( !opengl )

  The above constraints are a subset of the following complete expression:
    egl? ( !gles2 ) gles2? ( !egl !opengl ) opengl? ( X ) wayland? ( egl )

(dependency required by "media-plugins/gst-plugins-resindvd-1.4.5" [ebuild])
(dependency required by "media-plugins/gst-plugins-meta-1.0-r2[dvd]" [installed])
(dependency required by "@selected" [set])
(dependency required by "@world" [argument])

This might look scary, and it's indeed harder when there are multiple conflicts at the same time. That's why it's easier to handle when updating the system more often. Anyway, we'll solve them one at a time:

# emerge -1av icu

This was actually quite easy. Now perl can be more complicated, so let's use a command suggested by perl-cleaner:

# emerge -uD1a $(qlist -IC 'virtual/perl-*')
[blocks B      ] <sys-apps/openrc-0.13.8 ("<sys-apps/openrc-0.13.8" is blocking sys-apps/kmod-19)
[blocks B      ] <sys-apps/openrc-0.13 ("<sys-apps/openrc-0.13" is blocking sys-fs/udev-init-scripts-27)
 * Error: The above package list contains packages which cannot be
 * installed at the same time on the same system.

  (sys-apps/kmod-19:0/0::gentoo, ebuild scheduled for merge) pulled in by
    sys-apps/kmod required by (sys-apps/pciutils-3.2.0:0/0::gentoo, installed)
    >=sys-apps/kmod-15:0= required by (sys-apps/systemd-216-r3:0/2::gentoo, ebuild scheduled for merge)
    sys-apps/kmod[tools] required by (virtual/modutils-0:0/0::gentoo, installed)

  (sys-apps/openrc-0.12.4:0/0::gentoo, installed) pulled in by
    sys-apps/openrc required by @system
    >=sys-apps/openrc-0.12 required by (net-misc/netifrc-0.2.2:0/0::gentoo, installed)
    sys-apps/openrc required by (virtual/service-manager-0:0/0::gentoo, installed)

  (sys-fs/udev-init-scripts-27:0/0::gentoo, ebuild scheduled for merge) pulled in by
    >=sys-fs/udev-init-scripts-25 required by (sys-apps/systemd-216-r3:0/2::gentoo, ebuild scheduled for merge)

More blockers, and seemingly unrelated. Anyway, we have to resolve the blocker first, let's try:

# emerge -1av openrc udev-init-scripts
[blocks B      ] <sys-process/procps-3.3.9-r2 ("<sys-process/procps-3.3.9-r2" is blocking sys-apps/openrc-0.13.11)

 * Error: The above package list contains packages which cannot be
 * installed at the same time on the same system.

  (sys-process/procps-3.3.9:0/0::gentoo, installed) pulled in by
    sys-process/procps required by (app-emulation/open-vm-tools-2013.09.16.1328054-r3:0/0::gentoo, installed)
    sys-process/procps required by @system

  (sys-apps/openrc-0.13.11:0/0::gentoo, ebuild scheduled for merge) pulled in by
    sys-apps/openrc required by @system
    openrc
    sys-apps/openrc required by (virtual/service-manager-0:0/0::gentoo, installed)
    >=sys-apps/openrc-0.12 required by (net-misc/netifrc-0.2.2:0/0::gentoo, installed)

Finally, after including procps explicitly, it works! Don't forget to update config files when portage prompts about that.

# emerge -1av openrc udev-init-scripts procps
# dispatch-conf

What were we doing before? Okay, back to perl, and looks like it's going to work this time...

# emerge -uD1a $(qlist -IC 'virtual/perl-*')
# emerge -1av @preserved-rebuild

Next remaining piece was X. Trying to emerge it explicitly gives a more detailed message:

# emerge -1av xorg-server

WARNING: One or more updates/rebuilds have been skipped due to a dependency conflict:

x11-proto/fontsproto:0

  (x11-proto/fontsproto-2.1.3:0/0::gentoo, ebuild scheduled for merge) conflicts with
    <x11-proto/fontsproto-2.1.3 required by (x11-libs/libXfont-1.4.8:0/0::gentoo, installed)
    ^                     ^^^^^

Let's try emerging just libXfont... and it works!

# emerge -1av libXfont
# emerge -1av xorg-server

Finally, the USE flag constraints:

# euse -D gles2

I hope you found this useful. Especially things like $(qlist -IC 'virtual/perl-*') could be hard to find otherwise I guess.

5 comments:

Unknown said...

Wish I had this information a week ago while trying to resolve an issue with tetex.
cheers

Bla said...

Hey, … This shows what is being tried, without any explanation /why/ it is done. Which unfortunately makes is very useless.
Could you explain the reasoning behind, of all possible actions, picking those? Not just the idea behind picking the packets that are in conflict, but the idea that you can just run emerge for those packets, and it will work without changing anything in /etc/portage/ whatsoever!
How can it have a conflict when updating @world, but not when updating @world (in a slightly different order)? And why does portage not just change the order like that itself when failing to do it normally?
(I’m already thinking of a bash script that scans $(emerge -puDNtv world)’s output for which packages contribute to blockers, separates them by package categories, and tries to emerge them manually, before retrying the update. But it would probably work much better, if I knew what was going on…)

Nickname unavailable said...

I'm still having this exact conflict two years later, I agree with the previous comment that this help is unreadable because it doesn't explain anything and it uses the emerge abbreviations that might be easy to type but are much more difficult to either read or remember. Why is this STILL a problem? I found a bug report on this from 2013....

Unknown said...

Hey guys, I'm not sure how this could be explained better. If you can compare error messages you're getting with ones in this post, and try to take similar/analogous actions, it might help. While portage has improved a lot here, there's probably still much to do. Also see https://research.swtch.com/version-sat for some reasons why dependency resolution can be quite complex.

Alwyn Schoeman said...

E.g. Why did you pick a specific command for a specific situation?

Post a Comment