On 6 January 2016 at 13:48, Toshio Kuratomi 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 | [email protected] | Brisbane, Australia
___
python-devel mailing list
[email protected]
http://lists.fedoraproject.org/admin/lists/[email protected]
