Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 159310 - portage slot collision notice overshadows unresolvable blockers
Summary: portage slot collision notice overshadows unresolvable blockers
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High critical (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords: InVCS, REGRESSION
Depends on:
Blocks: 300071 147007 385391
  Show dependency tree
 
Reported: 2006-12-28 14:23 UTC by Jakub Moc (RETIRED)
Modified: 2011-10-02 18:52 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
don't show a slot collision notice if there are unresolvable blockers (blockers.patch,2.10 KB, patch)
2006-12-29 03:12 UTC, Zac Medico
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jakub Moc (RETIRED) gentoo-dev 2006-12-28 14:23:58 UTC
# 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.
Comment 1 Alon Bar-Lev gentoo-dev 2006-12-28 14:41:15 UTC
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.
Comment 2 Jakub Moc (RETIRED) gentoo-dev 2006-12-28 15:07:13 UTC
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.
Comment 3 Alon Bar-Lev gentoo-dev 2006-12-28 15:12:43 UTC
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.
Comment 4 Jakub Moc (RETIRED) gentoo-dev 2006-12-28 15:25:51 UTC
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.
Comment 5 Zac Medico gentoo-dev 2006-12-28 16:50:10 UTC
(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?
Comment 6 Jakub Moc (RETIRED) gentoo-dev 2006-12-28 16:56:47 UTC
(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.
Comment 7 Zac Medico gentoo-dev 2006-12-28 17:02:58 UTC
(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.
Comment 8 Alon Bar-Lev gentoo-dev 2006-12-28 23:53:01 UTC
So how to we progress with this issue?
bug#1303 is quite old...
Any workaround?
Comment 9 Zac Medico gentoo-dev 2006-12-29 00:24:11 UTC
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?
Comment 10 Zac Medico gentoo-dev 2006-12-29 00:34:22 UTC
Nevermind, I see why it's happening how.  I'll thing about a solution...
Comment 11 Zac Medico gentoo-dev 2006-12-29 03:12:53 UTC
Created attachment 104914 [details, diff]
don't show a slot collision notice if there are unresolvable blockers

This is fixed in svn r5413.
Comment 12 Jakub Moc (RETIRED) gentoo-dev 2006-12-29 03:23:42 UTC
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

Comment 13 Jakub Moc (RETIRED) gentoo-dev 2006-12-29 03:37:01 UTC
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
Comment 14 Jakub Moc (RETIRED) gentoo-dev 2006-12-29 04:07:17 UTC
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).
Comment 15 Zac Medico gentoo-dev 2006-12-29 22:30:06 UTC
This has been released in 2.1.2_rc4-r3.
Comment 16 Alon Bar-Lev gentoo-dev 2006-12-30 03:00:43 UTC
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?
Comment 17 Jakub Moc (RETIRED) gentoo-dev 2006-12-30 03:14:12 UTC
(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.)
Comment 18 Alon Bar-Lev gentoo-dev 2006-12-30 03:20:59 UTC
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.
Comment 19 Jakub Moc (RETIRED) gentoo-dev 2006-12-30 03:33:32 UTC
(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.

Comment 20 Alon Bar-Lev gentoo-dev 2006-12-30 07:45:55 UTC
OK.
But the first stage is to unmask the 2.0.1-r1 version.
Do you confirm this?
Comment 21 Jakub Moc (RETIRED) gentoo-dev 2006-12-30 08:51:58 UTC
(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 :) 

Comment 22 Alon Bar-Lev gentoo-dev 2006-12-30 09:28:26 UTC
Unmasked.
Thanks!
Comment 23 Alex V. Koval 2007-01-17 05:48:02 UTC
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] 
Comment 24 Bo Ørsted Andresen (RETIRED) gentoo-dev 2007-01-17 06:15:38 UTC
(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...