When there are resolvable and non-resolvable conflicts, the resolvable slot conflicts are displayed in-line with the non-resolvable ones. That leaves the user no way to tell which slot conflict actually needs to be resolved manually (by masking packages), and which slot conflicts will be implicitly resolved by portage. Clearly stating which slot conflict actually inhibits the merge will save us quite some hassle there. Reproducible: Always Steps to Reproduce:
The URL documents my initial misunderstanding of one such message. Turns out it was actually only some libopensync mess that kept emerge from proceeding, but in the message all conflicts looked the same.
Please post the emerge command you run, add --tree to the emerge options (if you don't have) and attach emerge's full output. Also attach emerge --info.
Sorry I wasn't concrete enough. The problem is messages like this: !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: net-libs/xulrunner:1.9 ('installed', '/', 'net-libs/xulrunner-1.9.0.14', 'nomerge') pulled in by =net-libs/xulrunner-1.9.0* required by ('installed', '/', 'www-client/mozilla-firefox-3.0.14', 'nomerge') (and 6 more) ('ebuild', '/', 'net-libs/xulrunner-1.9.1.4', 'merge') pulled in by >=net-libs/xulrunner-1.9.0.11-r1:1.9 required by ('installed', '/', 'net-libs/libproxy-0.2.3-r2', 'nomerge') >=net-libs/xulrunner-1.8 required by ('installed', '/', 'media-video/vlc-1.0.3', 'nomerge') net-libs/xulrunner:1.9 required by ('installed', '/', 'gnome-extra/yelp-2.28.0', 'nomerge') (and 3 more) x11-base/xorg-server:0 ('ebuild', '/', 'x11-base/xorg-server-1.7.1', 'merge') pulled in by x11-base/xorg-server required by ('installed', '/', 'media-video/nvidia-settings-190.42', 'nomerge') >=x11-base/xorg-server-1.5.99.901 required by ('installed', '/', 'x11-drivers/xf86-input-mouse-1.5.0', 'nomerge') x11-base/xorg-server required by @world (and 5 more) ('ebuild', '/', 'x11-base/xorg-server-1.6.5-r1', 'merge') pulled in by <x11-base/xorg-server-1.6.99 required by ('installed', '/', 'x11-drivers/nvidia-drivers-180.60', 'nomerge') (and 8 more) app-pda/libopensync:0 ('ebuild', '/', 'app-pda/libopensync-0.39', 'merge') pulled in by =app-pda/libopensync-0.39* required by ('ebuild', '/', 'app-pda/libopensync-plugin-file-0.39', 'merge') (and 1 more) ('installed', '/', 'app-pda/libopensync-0.36-r1', 'nomerge') pulled in by =app-pda/libopensync-0.36* required by ('installed', '/', 'app-pda/libopensync-plugin-gnokii-0.36', 'nomerge') =app-pda/libopensync-0.36* required by ('installed', '/', 'app-pda/msynctool-0.36', 'nomerge') (and 1 more) This tells me there's a ton of slot conflicts and naturally, I'll start working through them from top to bottom. However the above two are *automatically resolvable*, hence not real conflicts. Once I mask >=libopensync-0.39, portage proceeds as expected, resolving the "conflicts" with xulrunner and xorg-server by just leaving them alone. This then yields the following message: !!! One or more updates have been skipped due to a dependency conflict: x11-base/xorg-server:0 ('ebuild', '/', 'x11-base/xorg-server-1.7.1', 'merge') conflicts with <x11-base/xorg-server-1.6.99 required by ('installed', '/', 'x11-drivers/nvidia-drivers-180.60', 'nomerge') net-libs/xulrunner:1.9 ('ebuild', '/', 'net-libs/xulrunner-1.9.1.4', 'merge') conflicts with =net-libs/xulrunner-1.9.0* required by ('installed', '/', 'www-client/mozilla-firefox-3.0.14', 'nomerge') Which is expected and perfectly OK. What I'm saying is that it's just confusing to have the resolvable conflicts displayed in-line with non-resolvable ones, with no way to tell them apart. The xulrunner and xorg-server conflicts should somehow be labeled as non-fatal, i.e. resolvable, by putting them at the end and giving them an extra headline stating their status, for example. Just to be perfectly clear: This bug is not about a slot conflict, but about the *formatting* of slot conflict *messages*.
It may be that you have so many conflicts that you're just hitting the backtracking limit (default is 5). In light of this, all three conflicts are essentially equivalent. You can set a higher backtracking limit, such as --backtrack=10 in make.conf in EMERGE_DEFAULT_OPTS.
(In reply to comment #4) > It may be that you have so many conflicts that you're just hitting the > backtracking limit (default is 5). In light of this, all three conflicts are > essentially equivalent. You can set a higher backtracking limit, such as > --backtrack=10 in make.conf in EMERGE_DEFAULT_OPTS. > The message I've posted above is the entire slot conflict message. Seems like I still haven't made myself clear. The message above is simply *wrong* in that it gives false information, i.e. it lacks the essential information that two of those three conflicts are not actually conflicts. The correct message should look something like this: !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: app-pda/libopensync:0 ('ebuild', '/', 'app-pda/libopensync-0.39', 'merge') pulled in by =app-pda/libopensync-0.39* required by ('ebuild', '/', 'app-pda/libopensync-plugin-file-0.39', 'merge') (and 1 more) ('installed', '/', 'app-pda/libopensync-0.36-r1', 'nomerge') pulled in by =app-pda/libopensync-0.36* required by ('installed', '/', 'app-pda/libopensync-plugin-gnokii-0.36', 'nomerge') =app-pda/libopensync-0.36* required by ('installed', '/', 'app-pda/msynctool-0.36', 'nomerge') (and 1 more) !!! One or more updates have been skipped due to a dependency conflict: x11-base/xorg-server:0 ('ebuild', '/', 'x11-base/xorg-server-1.7.1', 'merge') conflicts with <x11-base/xorg-server-1.6.99 required by ('installed', '/', 'x11-drivers/nvidia-drivers-180.60', 'nomerge') net-libs/xulrunner:1.9 ('ebuild', '/', 'net-libs/xulrunner-1.9.1.4', 'merge') conflicts with =net-libs/xulrunner-1.9.0* required by ('installed', '/', 'www-client/mozilla-firefox-3.0.14', 'nomerge') Note that the messages for xulrunner and xorg-server have been replaced by the correct message stating their status and the order has been changed. This message clearly states that the libopensync conflict requires manual intervention whereas the xulrunner and xorg-server conflicts will be resolved automatically. That and nothing more is what I'm talking about. It's simply a nice usability enhancement. Unfortunately I don't know python and portage, but if no one is willing to look into this, I'm perfectly fine with digging myself in and posting a patch, however that'll take time.
(In reply to comment #5) > The message I've posted above is the entire slot conflict message. Seems like I > still haven't made myself clear. The message above is simply *wrong* in that it > gives false information, i.e. it lacks the essential information that two of > those three conflicts are not actually conflicts. What I'm trying to say is that all three of them are "not actually conflicts" if you use a larger value for --backtrack, such as --backtrack=10.
(In reply to comment #6) > (In reply to comment #5) > > The message I've posted above is the entire slot conflict message. Seems like I > > still haven't made myself clear. The message above is simply *wrong* in that it > > gives false information, i.e. it lacks the essential information that two of > > those three conflicts are not actually conflicts. > > What I'm trying to say is that all three of them are "not actually conflicts" > if you use a larger value for --backtrack, such as --backtrack=10. > Oh. Right. Thanks. But it would be really nice (i.e. more people would get to appreciating it) if there was some hint in the slot conflict message that I might resolve this by using --backtrack.
Ok, it's fixed in svn r14875 to give a hint about the --backtrack option: It may be possible to solve this problem by using package.mask to prevent one of those packages from being selected. However, it is also possible that conflicting dependencies exist such that they are impossible to satisfy simultaneously. If such a conflict exists in the dependencies of two different packages, then those packages can not be installed simultaneously. You may want to try a larger value of the --backtrack option, such as --backtrack=30, in order to see if that will solve this conflict automatically.
This is fixed in 2.1.7.7 and 2.2_rc52.
