Upstream installs 'python${SLOT}-config'. Gentoo installs 'python-config-${SLOT}'. Why? Right now I have to hack a random package to get it to find python-config. That's a bad thing and shouldn't happen. I already imagine random packages failing to build for other distros because they were designed for Gentoo's rename wannabe. I suggest we get back to the old name. We can do that on the p.masked ebuilds now to unleash all the breakage at once.
Do we know the rationale for differing from upstream? If it's simply historic, then I'm all for changing it back.
A quick grep shows the following packages are hacked around for python-config: - dev-libs/libxml2, - dev-libs/newt [in patch], - sys-apps/systemd, - sys-libs/tdb, - www-servers/uwsgi.
http://svn.python.org/view?view=revision&revision=50800 http://hg.python.org/cpython/rev/02fa1015cbcc/ http://svn.python.org/view?view=revision&revision=50984 http://hg.python.org/cpython/rev/29c7635d0199/
liquidx introduced python-config-${version} versioning in CPython 2.4 26 days after upstream changed versioning in CPython 2.5 from python-config${version} to python${version}-config. (Upstream never backported versioning to 2.4 branch.) http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-lang/python/python-2.4.3-r1.ebuild?revision=1.18&view=markup#l187 http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-lang/python/python-2.4.3-r2.ebuild?hideattic=0&view=log http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-lang/python/python-2.4.3-r2.ebuild?revision=1.1&view=markup#l191
Python 2.5 was released on 2006-09-19 (after all above changes). http://www.python.org/download/releases/2.5/
We still need a plan. Can you estimate how wide the use of python-config-* can be? If that's just those ebuilds, we can probably get with fixing them and adding versioned deps there. If it's something better, we'd probably need a compat symlink.
(In reply to comment #6) > We still need a plan. > > Can you estimate how wide the use of python-config-* can be? If that's just > those ebuilds, we can probably get with fixing them and adding versioned > deps there. If it's something better, we'd probably need a compat symlink. We would also need to push out an update for eselect-python, which generates the /usr/bin/python-config wrapper. I think compat symlinks would be wise choice.
Ok, the rename removed from p.masked ebuilds and compatibility symlinks added instead. I guess we'd think of phasing it out after the relevant versions go stable. /var/cvsroot/gentoo-x86/dev-lang/python/python-2.7.3-r3.ebuild,v <-- python-2.7.3-r3.ebuild new revision: 1.4; previous revision: 1.3 /var/cvsroot/gentoo-x86/dev-lang/python/python-2.5.4-r5.ebuild,v <-- python-2.5.4-r5.ebuild new revision: 1.4; previous revision: 1.3 /var/cvsroot/gentoo-x86/dev-lang/python/python-3.2.3-r2.ebuild,v <-- python-3.2.3-r2.ebuild new revision: 1.4; previous revision: 1.3 /var/cvsroot/gentoo-x86/dev-lang/python/python-3.3.0-r1.ebuild,v <-- python-3.3.0-r1.ebuild new revision: 1.4; previous revision: 1.3 /var/cvsroot/gentoo-x86/dev-lang/python/python-3.1.5-r1.ebuild,v <-- python-3.1.5-r1.ebuild new revision: 1.4; previous revision: 1.3 /var/cvsroot/gentoo-x86/dev-lang/python/python-2.6.8-r1.ebuild,v <-- python-2.6.8-r1.ebuild new revision: 1.4; previous revision: 1.3
Ok, it seems that newest ~arch packages are finally free of python-config-X.Y references. I think we should remove the compat symlink from ~arch soon, at least from py3.4.
That's fixed in new revisions of all supported Python versions already.
