# emerge -NuDpv world These are the packages that would be merged, in order: Calculating world dependencies | !!! Multiple versions within a single package slot have been !!! pulled into the dependency graph: ('ebuild', '/', 'app-crypt/gnupg-1.4.6', 'nomerge') pulled in by ('ebuild', '/', 'app-crypt/gnupg-2.0.1', 'merge') ('ebuild', '/', 'app-crypt/gnupg-2.0.1-r1', 'merge') pulled in by ('ebuild', '/', 'x11-plugins/enigmail-0.94.1', 'nomerge') ('ebuild', '/', 'app-crypt/gpgme-1.1.2-r1', 'nomerge') 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. For more information, see MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. !!! Problem resolving dependencies for app-crypt/gnupg:1.9 !!! Depgraph creation failed. Well done, that will bug a nice flood of pointless bugs.
What do you recommend? The side-by-side (1.4, 1.9) should be canceled when moving to 2.0 series. While people that uses 1.9 may mask >=2.0 if they have problems. I can mask it again if you like, but please instruct me what is the right process to unmask it, while current state is two sloted branches that needs to be combined into one.
I don't really know what are you planning to do but making emerge -uD world fail for everyone who uses gnupg is completely unviable solution; please re-mask this thing until there's some solution that doesn't utterly suck.
Done. I am opened to ideas... I don't know how it can be done. Nothing stable is effected... And I sent a notice three times to dev list.
Thanks. At minimum making portage actually respect the blocker dependency instead of spitting out this cryptic message that users plain don't understand would be an acceptable work-around for missing slotmerge functionality.
(In reply to comment #1) > two sloted branches that needs to > be combined into one. Can you use a slotmove for that? (In reply to comment #4) > At minimum making portage actually respect the blocker dependency instead of > spitting out this cryptic message that users plain don't understand would be an > acceptable work-around for missing slotmerge functionality. Which blocker dependency is that?
(In reply to comment #5) > Can you use a slotmove for that? Well, already tried here to move one or both slots, no luck here; maybe I'm missing some secret workaround... :) > Which blocker dependency is that? There's !<=app-crypt/gnupg-2.0.1 in gnupg-2.0.1-r1; it's completely ignored by recent portage versions.
(In reply to comment #6) > There's !<=app-crypt/gnupg-2.0.1 in gnupg-2.0.1-r1; it's completely ignored by > recent portage versions. It's certainly not ignored. I think what you are observing is that blockers are not processed until _after_ the entire dependency graph has been built (related to bug 1343), and in this case emerge dies before it has finished building the dependency graph.
So how to we progress with this issue? bug#1303 is quite old... Any workaround?
I don't understand why gnupg-2.0.1 was pulled in when gnupg-2.0.1-r1 is the highest available version. When I run `emerge -NuDpv world` here I get the normal blockers message: Calculating world dependencies... done! [blocks B ] <=app-crypt/gnupg-2.0.1 (is blocking app-crypt/gnupg-2.0.1-r1) [ebuild U ] app-crypt/gnupg-2.0.1-r1 [1.4.6] Jakub, can you trigger the "Multiple versions within a single package slot" error with --debug enabled and post the output here?
Nevermind, I see why it's happening how. I'll thing about a solution...
Created attachment 104914 [details, diff] don't show a slot collision notice if there are unresolvable blockers This is fixed in svn r5413.
OK, this is much better, still a bit funky... I'll try to mess w/ slotmove again a bit to see if I have any luck :) # emerge -uDav world These are the packages that would be merged, in order: Calculating world dependencies... done! [blocks B ] <=app-crypt/gnupg-2.0.1 (is blocking app-crypt/gnupg-2.0.1-r1) [ebuild U ] app-crypt/gnupg-2.0.1-r1 [1.4.6] USE="X (-bindist%) bzip2 caps%* (-curl%*) -doc% (-ecc%) (-idea%) -ldap nls -openct% -pcsc-lite% (-readline%*) (-selinux) -smartcard (-static%) (-usb%*) (-zlib%*)" LINGUAS="(-ru%)" 3,832 kB [ebuild U ] app-crypt/gnupg-2.0.1 [1.9.94] USE="X -doc gpg2-experimental -ldap nls -openct -pcsc-lite (-selinux) -smartcard" 0 kB Total: 2 packages (2 upgrades, 1 block), Size of downloads: 3,832 kB !!! Error: The above package list contains packages which cannot be installed !!! at the same time on the same system. For more information about Blocked Packages, please refer to the following section of the Gentoo Linux x86 Handbook (architecture is irrelevant): http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked
Meh... Now wondering whether this will leave 1.9.94 installed and will cause collisions or not... # qlist -CIev gnupg app-crypt/gnupg-1.4.6 app-crypt/gnupg-1.9.94 slotmove =app-crypt/gnupg-1.4.6 0 2 slotmove =app-crypt/gnupg-1.9* 1.9 2 # emerge -uDav world These are the packages that would be merged, in order: Calculating world dependencies... done! [ebuild U ] app-crypt/gnupg-2.0.1-r1 [1.4.6] USE="X (-bindist%) bzip2 caps%* (-curl%*) -doc% (-ecc%) (-idea%) -ldap nls -openct% -pcsc-lite% (-readline%*) (-selinux) -smartcard (-static%) (-usb%*) (-zlib%*)" LINGUAS="(-ru%)" 3,832 kB Total: 1 package (1 upgrade), Size of downloads: 3,832 kB
Well, no collisions, no blockers, all looks good :) app-crypt/gnupg selected: 1.9.94 1.4.6 protected: 2.0.1-r1 omitted: none >>> 'Selected' packages are slated for removal. >>> 'Protected' and 'omitted' packages will not be removed. The problem is, you'd have to stabilize 2.0.1-r1 and slotmove all the previous versions to SLOT="2" at the same time for this to be a feasible upgrade path. Otherwise it will be pretty messy for all stable users (basically creating third gnupg slot).
This has been released in 2.1.2_rc4-r3.
Thanks for the work guys! (In reply to comment #14) > The problem is, you'd have to stabilize 2.0.1-r1 and slotmove all the previous > versions to SLOT="2" at the same time for this to be a feasible upgrade path. > Otherwise it will be pretty messy for all stable users (basically creating > third gnupg slot). But I don't understand this one. Do you mean: 1. Unmask 2.0.1-r1. 2. None stable users will be prompted to unmerge older versions, they know how to handle that... They are using unstable tree... 3. Wait for bugs... 4. Slot move 1.9 slot into slot 0 + stabilize 2.0.1-r1 at the same time, so stable people will be forced to upgrade 1.4 and 1.9 series into 2.0 series. Right?
(In reply to comment #16) > 4. Slot move 1.9 slot into slot 0 + stabilize 2.0.1-r1 at the same time, so > stable people will be forced to upgrade 1.4 and 1.9 series into 2.0 series. No; you'd need to move all the stuff to a *new* slot (like SLOT="2"); the above won't work. (Or just stick w/ the blockers and let users handle it, it happens from time to time anyway and the above slot mangling is a bit hackish anyway.)
I cannot do any slot move until stage 4, since I need people to test it. And I don't really understand why moving all to slot 2 instead slot 0 at stage 4 makes any difference... If all stabilized and 1.9 is moved to slot 0, then all pervious packages share the same slot, and the upgrade to newer product (>=2.0.1-r1) will be allowed.
(In reply to comment #18) > And I don't really understand why moving all to slot 2 instead slot 0 at stage > 4 makes any difference... If all stabilized and 1.9 is moved to slot 0, then > all pervious packages share the same slot, and the upgrade to newer product > (>=2.0.1-r1) will be allowed. Not really; I've been playing with this for quite some time. Moving slot 1.9 to slot 0 still produces blockers; you can verify this pretty easily on a box with 1.4* and 1.9* setup.
OK. But the first stage is to unmask the 2.0.1-r1 version. Do you confirm this?
(In reply to comment #20) > But the first stage is to unmask the 2.0.1-r1 version. > Do you confirm this? We should move this somewhere else... :) Yeah, noone will stabilize a p.masked ebuild I guess :)
Unmasked. Thanks!
not sure if this is correct, when I try to install gnupg emerge tries to install 2 versions always. I even tried to specify exact version - no luck... appserver ~ # emerge -av =gnupg-1.9.21 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] app-crypt/gnupg-1.4.6 USE="X curl nls readline zlib -bindist -bzip2 -ecc -idea -ldap (-selinux) -smartcard -static -usb" LINGUAS="ru" 2,992 kB [ebuild N ] app-crypt/gnupg-1.9.21 USE="X nls -gpg2-experimental -ldap (-selinux) -smartcard" 0 kB Total size of downloads: 2,992 kB Would you like to merge these packages? [Yes/No]
(In reply to comment #23) > not sure if this is correct, when I try to install gnupg emerge tries to > install 2 versions always. I even tried to specify exact version - no luck... If you look in the 1.9.21 ebuild you'll see that it depends on "=app-crypt/gnupg-1.4*". 1.4 and 1.9 are slotted so this is supposed to happen. This bug is about >=gnupg-2.0.1 which replaces both of 1.4 and 1.9...
