I just finished updating my machine when I ran into an issue I have no clue how to resolve. I'm a long-time Gentoo user, but I'm a truck driver not a programmer.

One of the packages that was updated was dev-python/simplejson-3.0.4-r1 (which apparently is a dependency for chromium) When I finished updating portage gave me the following output:

Code:

* Messages for package dev-python/simplejson-3.0.4-r1:

* It seems that you need to set USE_PYTHON to make sure that legacy
* packages will be built with respect to PYTHON_TARGETS correctly:
*
* USE_PYTHON='2.7'
*
* Please note that after changing the USE_PYTHON variable, you may need
* to run 'python-updater' to rebuild affected packages.
*
* For more information on python.eclass compatibility, please see
* the appropriate python-r1 User's Guide chapter [1].
*
* [1] http://www.gentoo.org/proj/en/Python/python-r1/user-guide.xml#doc_chap2

Well I read the guide linked to above, and now I'm more confused than ever as I've never had USE_PYTHON=, PYTHON_SINGLE_TARGET=, PYTHON_TARGETS= set in my make.conf before.

I've always just used eselect python to set the interpretor and have never had any issues.

I currently have installed dev-lang/python-2.7.3-r3 and dev-lang/python-3.2.3-r2, with python-3.2 set as default via eselect. (I've had python-3.x set as my default since the summer with no issues.)

When I run eselect python list I get this:

Code:

Available Python interpreters:
[1] python2.7
[2] python3.2 *

Now here is where I get completely confused. As I said, I've never set anything about python in my make.conf except for USE="python3" for portage.
However, if I run emerge --info I get PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" and USE_PYTHON is unset.

So what is going on and where do I go from here? Do I set USE_PYTHON="3.2" and PYTHON_SINGLE_TARGET="3.2" to keep consistent with eselect? Is eselect now deprecated and ignored? Do I even have to set these values at all in my make.conf?

Somebody knowledgeable please chime in, before I rip what little hair I have left out! lol

I've tried setting it in make.conf, /etc/portage/package.use, and on the command line for cinnamon (such as PYTHON_SINGLE_TARGET="python2_7" emerge cinnamon), but nothing seems to do the trick. I also ran python-updater, which rebuilt 16 packages successfully. Emerge --info says PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" even without it set in make.conf, so this is very curious. Is this still the python-r1.eclass bug?

This is an otherwise ~x86 system in seemingly perfect running order, up-to-date, depcleaned, and revdep-rebuild shows nothing

If you are running a modern system with only Python 2.7 & 3.2 installed, then you don't have to do anything. The defaults will simply fit you, and let you keep your system up-to-date when new Python versions are deployed. However, if you'd like to use another set of Python implementations, you will need to set PYTHON_TARGETS in your make.conf file appropriately.

So, there is no need to define these in make.conf, and it may be failing for that reason (guess).

dev-libs/gobject-introspection has PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7" so most like this would work without any intervention.

So, why is PYTHON_SINGLE_TARGET unset by default on this package?
If I try to set PYTHON_SINGLE_TARGET="python2_7" in make.conf, it also wont work. The only way is to set manually before the emerge commad.

So, why is PYTHON_SINGLE_TARGET unset by default on this package? If I try to set PYTHON_SINGLE_TARGET="python2_7" in make.conf, it also wont work. The only way is to set manually before the emerge commad.

ccube ... I think the issue is that PYTHON_SINGLE_TARGET is designed to overide PYTHON_TARGETS for cases in which "only a single Python implementation can be enabled", in the case above there is a change in TARGET, PYTHON_SINGLE_TARGET="-python2_7*" will set that value to null, and so "tak[ing] precedence over PYTHON_TARGETS" nothing is passed as TARGET.

I'm still not altogether sure how the whole thing is ment to work, but given that it should work without having to define anything (at least when not requiring "another set of Python implementations") its probably a case that having it in make.conf causes emerge to take this value more literally, that again, is mostly guesswork.

Since it is set, but not recognized, it looks like a bug for me. But why are no other people affected? Any tips where to look at next?

ccube ... yes, its set, as it is here without ever having added any *_TARGET in make.conf, but as I said, in the above it looks to have been changed, and so you had "-python2_7*" (a use change). This may have been the result of the package having been changed, or the effect of the additon of *_TARGETS in make.conf, I'm not sure. The basic point, I think, is that there shouldn't be any need to do anything with *_TARGETS unless you have needs outside of those provided by the default.

The behavior does seem to point to a bug, if nothing was changed in the package that is, but I can't really say any more than that without trying to replicate it, and gobject-introspection is something I have blocked.