On 6 January 2016 at 13:48, Toshio Kuratomi <a.bad...@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. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ python-devel mailing list python-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
