On 6 January 2016 at 13:48, Toshio Kuratomi <a.badger(a)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 | ncoghlan(a)gmail.com | Brisbane, Australia