Summary: | gnome package determines python version on their own (and wrong) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Robert Buchholz (RETIRED) <rbu> |
Component: | New packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | arfrever, esigra, leonchik1976, mstamat |
Priority: | High | Keywords: | InOverlay |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 262490 |
Description
Robert Buchholz (RETIRED)
2009-03-12 09:18:06 UTC
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. |