python.eclass currently exports the pkg_setup function under the following circumstances:
EAPI 2, 3: When ${PYTHON_USE_WITH} or ${PYTHON_USE_WITH_OR} are defined.
EAPI 4: Always exported.
I would like to modify python.eclass to export pkg_setup
unconditionally, rather than checking EAPI and random variables. This
will make the eclass behave more consistently, which seems like a good
thing.
This may cause problems in ebuilds which inherit python after another
eclass which exports pkg_setup if the ebuild does not override pkg_setup
itself. For example:
EAPI=3
inherit fortran-2 python
With a bit of hackery in ebuild.sh (thanks to Arfrever), I have compiled
a list of ebulids which may need to be modified. This will generally
mean reordering the eclasses in the inherit line, or defining a
pkg_setup function in the ebuild.
Barring any objections, I will make any necessary modifications to these
ebuilds over the next week or so, and commit the change to python.eclass
next weekend. If anyone has a better idea for rolling this out, please
speak up. :)
Here is the list of ebuilds, along with the pkg_setup function being
overridden.
gentoo-x86:
app-portage/maintainer-helper-0.1.2: qt4_pkg_setup
dev-python/pypy-1.7: check-reqs_pkg_setup
media-plugins/mythnetvision-0.23.1_p26407: mythtv-plugins_pkg_setup
sci-chemistry/pdb-tools-0.1.4-r3: fortran-2_pkg_setup
sci-chemistry/pdb2pqr-1.5.0-r2: fortran-2_pkg_setup
sci-chemistry/pdb2pqr-1.7.0: fortran-2_pkg_setup
sci-libs/libsvm-2.90-r1: java-pkg-opt-2_pkg_setup
sci-libs/libsvm-3.0: java-pkg-opt-2_pkg_setup
sci-physics/camfr-20070717-r2: fortran-2_pkg_setup
www-apache/mod_wsgi-3.3: apache_pkg_setup
www-apps/venus-20100911: webapp_pkg_setup
sunrise:
games-puzzle/pythonsudoku-0.13: games_pkg_setup
games-rpg/pylotro-0.1.14: games_pkg_setup
media-libs/portmidi-217: java-pkg-opt-2_pkg_setup
signature.asc
Description: OpenPGP digital signature
