I think I caught a weird confluence of circumstances (and I can just ram through this manually), but it seems like a logic bug exists that could reappear later). I started an emerge of KDE 3.3.2, and (due to a network connectivity problem), the emerge died right after it upgraded arts to 1.3.2 (and nothing else). When I went to restart the emerge (--resume failed for some reason - "nothing to resume"), I got this: # emerge -Dptuv world These are the packages that I would merge, in reverse order: Calculating world dependencies ...done! [ebuild U ] kde-base/kde-3.3.2 [3.3.1] 0 kB [ebuild U ] kde-base/kdegames-3.3.2 [3.3.1] +arts -debug +xinerama 9,116 kB [ebuild U ] kde-base/kdeedu-3.3.2 [3.3.1] +arts -debug +xinerama 21,552 kB [ebuild U ] kde-base/kdenetwork-3.3.2 [3.3.1-r1] +arts -debug +samba -slp +ssl +wifi +xinerama 6,796 kB [ebuild U ] kde-base/kdetoys-3.3.2 [3.3.1] +arts -debug +xinerama 2,696 kB [ebuild U ] kde-base/kdeaddons-3.3.2 [3.3.1] +arts -debug -esd +sdl +svga +xinerama +xmms 1,527 kB [ebuild U ] kde-base/kdemultimedia-3.3.2 [3.3.1] +alsa +arts -audiofile +cdparanoia -debug +encode +flac +oggvorbis +speex -xine +xinerama 5,258 kB [ebuild U ] kde-base/kdepim-3.3.2 [3.3.1] +arts -cjk +crypt -debug -gnokii -pda +xinerama 9,759 kB [ebuild U ] kde-base/kdeutils-3.3.2 [3.3.1] +arts -debug +xinerama 2,159 kB [ebuild U ] kde-base/kdeartwork-3.3.2 [3.3.1] +arts -debug +opengl +xinerama -xscreensaver 17,559 kB [ebuild U ] kde-base/kdeadmin-3.3.2 [3.3.1] +arts -debug +pam +xinerama 1,521 kB [ebuild U ] kde-base/kdewebdev-3.3.2 [3.3.1] +arts -debug -doc +xinerama 4,685 kB [ebuild U ] kde-base/kdeaccessibility-3.3.2 [3.3.1] +arts -debug +xinerama 1,213 kB [ebuild U ] kde-base/kdegraphics-3.3.2-r1 [3.3.1-r2] +arts -debug +gphoto2 +imlib -jpeg2k +opengl -povray +scanner -tetex +xinerama 6,088 kB [ebuild U ] kde-base/kdebase-3.3.2-r1 [3.3.1] +arts +cups -debug -java -ldap +opengl +pam +samba +ssl +xinerama 19,526 kB [1] [ebuild U ] kde-base/kdelibs-3.3.2-r1 [3.3.1-r2] +alsa +arts +cups -debug -doc +ipv6 -kerberos -ldap +ssl +tiff +xinerama 0 kB [nomerge ] kde-base/kde-i18n-3.3.1 +arts -debug +xinerama [nomerge ] kde-base/kdelibs-3.3.1-r2 +alsa +arts +cups -debug -doc +ipv6 -kerberos -ldap +ssl +tiff +xinerama [ebuild UD] kde-base/arts-1.3.1 [1.3.2] +alsa +arts -artswrappersuid -debug -esd -jack +mad +oggvorbis +xinerama 0 kB Total size of downloads: 109,460 kB Note that portage wants to downgrade arts to 1.3.1 (despite the -u flag), and more bizarrely, it shows kdelibs 3.3.1-r2 as a nomerge, but then would later upgrade kdelibs to 3.3.2-r1 (and both use the same slot). Obviously, not having kde-i18n 3.3.2 marked as stable (when I synced) contributed to the problem. Reproducible: Always Steps to Reproduce: Actual Results: It would have downgraded arts, but I didn't really want to waste the time to go through everything to see what would happen after that (no doubt, it would want to upgrade it again right away). Expected Results: Not what it wanted to do. :) I don't know how portage should respond when two different packages want two different versions of a dependency. Maybe it should report a blocking condition, or maybe it should just die and refuse to do anything. This doesn't seem too serious in the present situation (especially since someone told me that the developers have marked kde-i18n 3.3.2 as stable), but it certainly has the potetial to cause major problems in the future in a slightly different situation.
It did so because kde-i18n hadn't been marked stable yet for 3.3.2. It is now - just emerge sync.
Oops - should have finished reading the text first. Anyway, there is already a bug open that addresses this situation, IIRC.
