[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