On 6 January 2016 at 13:48, Toshio Kuratomi a.badger@gmail.com wrote:
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.
+1 from me for adopting newer package versions as baseline in the python3X stacks.
As Toshio notes, many of the components currently shipped don't support Python 3 yet, so they're going to *have* to be rebased before they can be part of a Python 3 stack: http://fedora.portingdb.xyz/
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.
It's also worth keeping in mind that the parallel install model adopting for the python3X releases in EPEL means there's a chance to rebase the "default" version of other packages each time "X" is incremented. While that won't be a big difference for the python34 and python35 stacks, there will presumably be more significant version bumps once python36 rolls around.
Regards, Nick.