On Tue, Jan 05, 2016 at 08:07:22PM -0700, Orion Poplawski wrote:

So, I've started packaging up a bunch of python3 only packages for EPEL7 for packages that were already in RHEL7. I've started by packaging the latest version of the modules:

python34-py.noarch 1.4.30-2.el7 epel-testing python34-setuptools.noarch 19.2-3.el7 epel-testing

But these are much newer than the python2 versions:

python-py.noarch 1.4.27-1.el7 python-setuptools.noarch 0.9.8-4.el7

I'm afraid I was motivated by the possibilities of supporting newer python3 code, but Matthias RUnge makes the valid point that this may cause confusion and other problems[1].

What's the consensus here?

1 - https://bugzilla.redhat.com/show_bug.cgi?id=1294865#c3

Matthias Runge is correct that there will be a confusion factor. That will be especially pronounced for libraries which are used specifically for compatibility between python2 and python3 (python-six, python-backports-*, python-future if someone packages it eventually). This confusion is cut down slightly by having a different naming scheme (34 rather than just 3) for these packages than the equivalents in Fedora. However, as the naming difference is small, the amount that it helps with the confusion is also small. We would have been in a lot better place today if we had separate packaging of python2 and python3 packages in Fedora so that they were never in sync there but that's not something we can probably change now....

Despite the confusion, my feeling is that we want the newer versions. People who want to run python3 are willing to live more on the bleeding edge. What I've observed is that they want newer versions of libraries as well. Building packages that nobody wants to use because they are too old isn't that helpful to those who want to use the system packages for their development. For us packagers, getting applications to run on python3 frequently needs newer versions of supporting libraries due to bugfixes for python3 going into those libraries. Attempting to pin the python34 versions to the versions that ship with RHEL or in EPEL as the python2 version will quickly become a hindrance to us in those efforts as well.

If we deem the confusion factor to be too great we could resort to the Debian library route and name packages with the library version number as well: python34-setuptools19, for example. But that carries its own set of problems: 1) Although we have a way (via setuptools/pkg_resources) to make both packaging of alternate modules and usage of the modules work it isn't as easy as working with modules packaged in the normal way. 2) If it's standard for us to package python34 modules as compat packages, our support burden will increase as people create packages for multiple versions of the upstream library. We (EPEL) need to figure out some policies on retiring old packages when they're no longer maintained. 3) If we're retiring unmaintained older versions of packages during the lifetime of a RHEL release then we probably need to figure out if our present method for determining the default python module (what version you get if you just do "import setuptools") is the best. The current way is basically, whichever version entered EPEL first is the default, all others are forward compat packages.

-Toshio