Bug 1120256

Thanks for the patch. How does this work? When compiled on a python3 system, does it produce both python3 and python2 files? Why would a python3 subpackage be needed? I don't really follow python programming at all and am not sure what the supporting spec file changes might be.

This is in upstream commit #60.

So, let me elaborate a bit:
There's an accepted systemwide Fedora change to make Python 3 the default Python interpreter in Fedora 22 [1]. That means two different things for different kinds of packages:
- "applications" (e.g. packages that are supposed to be used directly by Fedora users) should switch from Python 3 to Python 2 if possible
- "libraries" (e.g. something that other libraries/applications import and is not directly runnable) should start providing python3-* subpackages to be importable in Python 3
- Python 2 and Python 3 have different load paths and are not binary compatbile, so in the second case ("library", which applies to libcap-ng) both python- and python3- subpackages should be provided, so that people can use libraries on both interpreters.

The above means, that where possible, Python bindings should be built twice during rpmbuild and python3- subpackage (libcap-ng-python3 in your case) should be provided.
In term of specfile changes, I guess it's easier to build libcap-ng twice, once with
./configure PYTHON=%{__python2}
and once with
./configure PYTHON=%{__python3}

The motivation for libcap-ng specifically is, that it's on LiveCD and our primary target with [1] is to only have Python 3 on LiveCD - meaning that we need libcap-ng to provide python3 subpackage.
Hope this answers the questions - feel free to ask more if not!

[1] http://fedoraproject.org/wiki/Changes/Python_3_as_Default

Hi, I was doing some testing on RHEL6. Libcap-ng now fails to build by crashing in configure:

checking whether to create python bindings... testing
checking for python... /usr/bin/python
checking for python version... 2.6
checking for python platform... linux2
checking for python script directory... ${prefix}/lib/python2.6/site-packages
checking for python extension module directory... ${exec_prefix}/lib/python2.6/site-packages
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named sysconfig
configure: error: Python explicitly required and python headers found

Do you have any idea what was wrong? This is the patch:

https://fedorahosted.org/libcap-ng/changeset?reponame=&new=60%40trunk&old=59%40trunk

(In reply to Steve Grubb from comment #3)
> Hi, I was doing some testing on RHEL6. Libcap-ng now fails to build by
> crashing in configure:
> 
> checking whether to create python bindings... testing
> checking for python... /usr/bin/python
> checking for python version... 2.6
> checking for python platform... linux2
> checking for python script directory... ${prefix}/lib/python2.6/site-packages
> checking for python extension module directory...
> ${exec_prefix}/lib/python2.6/site-packages
> Traceback (most recent call last):
>   File "<string>", line 1, in <module>
> ImportError: No module named sysconfig
> configure: error: Python explicitly required and python headers found
> 
> Do you have any idea what was wrong? This is the patch:
> 
> https://fedorahosted.org/libcap-ng/
> changeset?reponame=&new=60%40trunk&old=59%40trunk

Sorry, this is my mistake from the previous patch. "sysconfig" is not available as a module in Python 2.6. Instead of "import sysconfig", you should use "from distutils import sysconfig" (the rest stays the same). This works in Python 2.6, 2.7 and 3.X.

OK. That fixed the problem. I confirm a good build on older OS. Thanks!

So, back in comment#2, it was mentioned that I would need to build the library twice. Is there another package that does this same thing? I am looking for an example. The project page doesn't really give any advice to packagers about how to do this or example spec file changes.

If I can work out the spec file changes, I'll go ahead and do a release and push it through the build system.

Here's how the libpwquality maintainer has handled it [1].

More generally, there are some notes on python3- subpackages building in Python packaging guidelines [2]. The examples are Python extension modules (e.g. not libraries with Python bindings like in this case), but the approach applies to any package that is supposed to be built against both Python major versions.

Hope this helps and thanks!

[1] http://pkgs.fedoraproject.org/cgit/libpwquality.git/commit/?id=c57e81ff0077f481fa98a5d98f6d406c7deab9d0
[2] http://fedoraproject.org/wiki/Packaging:Python#Building_more_than_once

Steve, is there anything else I can help with? It'd be really great if we could finish this and close the bug. Thanks!

Ping, anything I can help with here?

This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

This turned out to be quite challenging. It was a combination of swig, autotools, and python3 that made it an unholy mess. In any event, its now built in rawhide.