alacarte's configure does some magic loop to determine the largest python version available, which breaks if an earlier python version is selected via eselect (because modules are not found). # eselect python show python2.5 # emerge alacarte ... checking for python2.6... /usr/bin/python2.6 checking whether /usr/bin/python2.6 version is >= 2.6.0... yes checking for version... 2.6 checking for platform... linux2 checking for script directory... ${prefix}/lib64/python2.6/site-packages checking for extension module directory... ${exec_prefix}/lib64/python2.6/site-packages checking for x86_64-pc-linux-gnu-pkg-config... no checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for ALACARTE... yes checking for pygobject 2.15.1 installed for python required_python_abi... not found configure: error: required pygobject version not found This can be resolved by setting the PYTHON variable before running configure, as seen here (tested it as well): # AM_PATH_PYTHON_VERSION(ABI-VERSION1, [MINIMUM-VERSION1 [, ABI-VERSION2, [MINIMUM-VERSION2 ...]]]) # # An alternative to AM_PATH_PYTHON that checks for specific python ABI/version pairs. # Example: # AM_PATH_PYTHON_VERSION(2.3, 2.3.5, 2.4, 2.4.0) # checks for a python2.3 binary returning python version >= 2.3.5, and # if that fails it looks for python2.4 containing version >= 2.4.0 # It aborts configure with an error if no statisfying version is found. # Env. var. PYTHON can be used to point a specific/laternate version to configure.
Having this test perform one way or another is wrong in eselect case anyway. Most distribution simply won't allow having gnome package spread across multiple python slots so it's going to be a bit difficult to make changes to autoconf that will be taken upstream imho. Last time we had this (python 2.4 -> 2.5) we just said to our users to select one slot of python and remove the other.
A fix in the eclass would be the most appropriate I think if we are to set an env variable for configure. Would you like to submit a patch ?
I provided a patch in Bug 272428 which seems to be a duplicate.
*** Bug 272428 has been marked as a duplicate of this bug. ***
*** Bug 272559 has been marked as a duplicate of this bug. ***
*** Bug 283275 has been marked as a duplicate of this bug. ***
Note that this issue relates or is obsoleted by multiple python ABI support.
FTR, after the reopening of bug #327961, I checked the situation with the python eclass. Looks like the following addition to the alacarte ebuild, as an example, works just as expected: +pkg_setup() { + python_set_active_version 2 + G2CONF="${G2CONF} PYTHON=${EPYTHON}" +} Is adding something like this: if grep -q AM_PATH_PYTHON "${S}"/configure.{ac,in}; then G2CONF="${G2CONF} PYTHON=\"${EPYTHON}\"" fi to the gnome2 eclass in src_configure is ok even without depending on python eclass or should we create a gnome2-python eclass which should be used for all of our ebuilds providing python modules ? I think it's ok to not add python eclass dependency, but we could probably add a check so that we can catch ebuilds not inheriting eclass properly.
The problem I see in that is that in PYTHON=${EPYTHON}, EPYTHON does not return 2.6 but 2.7, instead.
Ignore what I wrote, I forgot to clean the env. It does work.
EPYTHON is rather internal variable used for communication between python.eclass and python-wrapper. I don't know how often AM_PATH_PYTHON_VERSION macro is used.
what could we use then that would tell us what is the currently selected python interpreter ?
(In reply to comment #12) $(PYTHON)
*** Bug 347335 has been marked as a duplicate of this bug. ***
FTR, I added a gnome2-python eclass a few weeks ago based on the suggestion of Arfrever. All herd members are encouraged to use it extensively so we can validate it before moving it to the tree.
This is definitively obsoleted by python eclass usage for multiple python ABI support (be it python-2* or python2 and python3). Considering the problem as fixed although we could go further by introducing the prototype gnome-python eclass from the overlay to the tree.
