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.el7epel-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
pgpxjpNAbt8Ie.pgp
Description: PGP signature
___
python-devel mailing list
[email protected]
http://lists.fedoraproject.org/admin/lists/[email protected]
