I was running emerge -pve world. I do this to catch any weird corner cases caused by my non-perfect understanding of emerge. I noticed it mentioned 2 in new slots so I went looking to find out what it was. Turned out it's python-2.6.8 and associated python-docs, running in tree mode resulting in my discovering webapp-config is what's pulling in python: Code: [ebuild R ] app-admin/webapp-config-1.50.16-r4 0 kB [ebuild NS ] dev-lang/python-2.6.8 [2.7.3-r2, 3.2.3] USE="doc gdbm ipv6 ncurses readline ssl threads (wide-unicode) xml -berkdb -build -examples -sqlite -tk -wininst" 10,885 kB A further confirmation of this is that if I run emerge -pve webapp-config it again mentions 2 in new slots and shows python as the one with a new slot. I put dev-lang/python-2.5 and dev-lang/python-2.6 in my package.mask file and it no longer pulled in a new slotted python (it didn't pull in any python-2) and didn't complain. Reproducible: Always Steps to Reproduce: 1. emerge -pvte webapp-config 2. Put dev-lang/python-2.5 and dev-lang/python-2.6 or just <dev-lang/python-2.7 in package.mask file. 3. Redo emerge -pvte webapp-config Actual Results: First emerge pulls in python-2.6.8 and second emerge doesn't pull in python-2.6.8 and doesn't fail. Expected Results: Either first emerge uses python-2.7 or second emerge fails because it can't emerge python 2.5/2.6. Originally formed this as a question of what was going on on the forum here: http://forums.gentoo.org/viewtopic-t-939642.html . Was told that if python happily didn't pull in python-2.6 with a package.mask entry I should file a bug.
This type of behavior is expected if python:2.7 is masked or its ebuild is unavailable. This command may provide some clue: emerge -pv dev-lang/python:2.7
Oh, sorry, I forgot to mention, I already have python-2.7 installed (which is why I am so confused why it wants to use 2.5/2.6). I'm pretty sure it isn't masked. When I ran "emerge -pvDuN --with-bdeps y world" I got: These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] x11-libs/gtksourceview-2.10.5-r2 USE="-glade -test (-doc%)" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB When I ran "emerge -pv dev-lang/python:2.7" I got (notice python-2.7 is already installed, so why didn't the "emerge -pvDuN --with-bdeps y world" catch it and complain): These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] dev-lang/python-2.7.3-r2 USE="doc gdbm ipv6 ncurses readline ssl threads (wide-unicode) xml -berkdb -build -examples -sqlite* -tk -wininst" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: dev-lang/python:2.7 (dev-lang/python-2.7.3-r2::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) (dev-lang/python-2.7.3-r2::gentoo, installed) pulled in by =dev-lang/python-2.7*[sqlite] required by (gnome-extra/hamster-applet-2.32.1::gentoo, installed) !!! Enabling --newuse and --update might solve this conflict. !!! If not, it might help emerge to give a more specific suggestion. I also don't understand how this would be connected to webapp-config seeing as how, as I read it, hamster-applet just requires some python-2 >=2.5 with sqlite. Seeing as how python-2.6.8 is not providing sqlite I don't see why it would be acceptable and python-2.7 would not. Also, I do not see how hamster applet would be involved in the "emerge -pve webapp-config", though I'd be less surprised if I'm just missing something on that part. Additionally, I wondered how python-2.7 could get rebuild in the "emerge -pve world"if it was conflicting with hamster-applet. I discovered by grepping "emerge -pve world" that python-2.7 is *NOT* in the list even though it's my selected python (by selected I mean eselect python list says I'm using 2.7).
gnome-extra/hamster-applet-2.32.1 has the following dependency: || ( =dev-lang/python-2.7*[sqlite] =dev-lang/python-2.6*[sqlite] =dev-lang/python-2.5*[sqlite] ) So, it seems as though emerge -e world pulls in python-2.6 since you have USE=sqlite enabled for it. This allows you do have sqlite disabled for python-2.7, yet still satisfy the hamster-applet dependency.
I had thought of the same idea, but as you can see from the original post, my python-2.6 that it wanted to grab has sqlite disabled.
I suspect that the python:2.7 sqlite thing is causing python:2.7 to be masked by backtracking, and maybe that's what forces python:2.6 into the graph. Please attach a debug log reproducing the problem as follows: emerge -pve world --debug &>debug.log
Created attachment 326734 [details] Debug log for webapp-config This shows the issue while being smaller. Not sure if it's useful but I thought I'd post it just in case. This is the result of: emerge -pve webapp-config --debug &> webapp-config-debug.log
Created attachment 326736 [details] Debug output from emerge Output of (then bzip2'd ofc): emerge -pve world --debug &> debug.log
It's like I described in comment #5. The slot conflict triggered by hamster-applet caused the python-2.7.3-r2 ebuild to be masked for backtracking purposes, and this caused the python-2.6.8 ebuild to be pulled in instead.