Comment 27 for bug 633640

Heh, I just tried it and noticed the test-suite actually still works. Which is supposed to be impossible because the python bindings dont get installed into the test-root when the bindings are not built through automake.

The trick is that unlike everything else, the python tests dont run through fakechroot as arranging a full python environment inside the root is rather tricky. What happens is that it just falls back to using system rpm-python bindings, which "works" as long as the system bindings are reasonably similar as the one currently being built. So the test-suite *appears* to work when building on eg F19, but would fail on F17.

There doesn't seem to be any sane way to hook the setup.py stuff into automake test-environment creation, but what we can do is leave --enable-python into configure for the test-suite, but nuke the automake-installed bindings from buildroot and then install the bindings with setup.py, ie

make DESTDIR="$RPM_BUILD_ROOT" install

rm -rf $RPM_BUILD_ROOT/%{python_sitearch}
pushd python
%{__python} setup.py install --skip-build --root $RPM_BUILD_ROOT
%{__python3} setup.py install --skip-build --root $RPM_BUILD_ROOT
popd

Of course this isn't optimal since the python2 bindings are getting built twice and the test-suite is now strictly speaking testing a different build than what gets packaged, but meh...