[Fedora-packaging] Proposal: naming convention for Python 3 packages and subpackages

David Malcolm dmalcolm at redhat.com
Fri Oct 30 00:15:01 UTC 2009


On Thu, 2009-10-29 at 18:42 -0400, John Dennis wrote:
> On 10/29/2009 06:27 PM, David Malcolm wrote:
> 
> > I rather like the idea of standardizing on a "python3-" prefix for _all_
> > Python 3 module packages and subpackages, even if this leads to
> > inconsistencies with their counterparts in the python 2 stack.  It would
> > make the "threeness" of the packages stand out more.
> >
> > Thoughts?
> 
> Initially this sounds good to me. Because python 2 and python 3 are 
> incompatible it's probably important we separate them at the packaging 
> level, this seems like a good approach as any (even with some warts on 
> the corner cases).
> 
> However package maintainers might not like the idea of having to 
> maintain double the number of their packages for an interim period and I 
> could see them wanting to have just one package that installs into both 
> the python2 and python3 library locations. Also perhaps we don't want to 
> inflate the number of python packages by 2x. Having not followed this 
> discussion from it's outset I'm wondering if we might want to consider 
> allowing a single python package to support both python versions. I'm 
> sure there are multiple reasons why this is a horrible idea, but I 
> thought I would throw it out for consideration and let it get shot down :-)

My original proposal [1] was that python 3 should be entirely separate
from python 2

As a trial run, I took a packaged python module and got it to build with
python 3.  See:
https://bugzilla.redhat.com/show_bug.cgi?id=531648

This is the separate-srpm approach, it would live as a separate package
in CVS.


As an experiment, I tried hacking up the same module's specfile so that
one build generates both 2 and 3 subpackages.  You can see the result
here:
https://bugzilla.redhat.com/show_bug.cgi?id=531895

This approach requires the package to work with both python 2 and 3,
which requires both an upstream maintainer and a downstream Fedora
packager that care about both 2 and 3, working from a single source
tree.


For supporting both 2 and 3 with a single built RPM (or something
involving symlinked .py files?) I don't think that's possible: we don't
want to add a python3 dependency to python 2 modules, and the
precompiled bytecode optimization of imports requires
version-specific .pyc/.pyo files - see bug 531117 (automating this in
rpmbuild) and bug 531102 (adding a test to rpmlint to verify that it got
it correct).

Dave

[1] See:
https://www.redhat.com/archives/fedora-devel-list/2009-October/msg00054.html
and https://fedoraproject.org/wiki/Features/Python3F13





More information about the Fedora-packaging mailing list