#70 Retire python34 proposal
Closed: Unable to Fix a year ago by smooge. Opened 2 years ago by smooge.

From email:

On Sun, 11 Aug 2019 22:26:45 +0200
Miro Hrončok mhroncok@redhat.com wrote:

%python3_other_pkgversion 34

I believe the easiest fix is to define that directly in


Correct. That fixes this issue but not the huge issue we have now.

Thanks for the report!

I agree. But we have much bigger problem with epel python naming.

python3_other is now defined to 3 in rhel7.7.

Because epel is supposed to add packages to rhel, we have now new
definition which is our master. That means with 7.7 system and mock,
there is no possibility to build python36 packages any more.

Because rhel selected python3 naming when inroduced python3 that gives
epel7 new baseline for naming standard for python3 packages which means
we should now follow that on epel7 post rhel7.7. Before python3 was
added to rhel we could play with python3x naming freely but not any

We have two choises really, this suggestion of mine is based on the
expectation that rhel7 continues to have more python3 packages in
future with naming python3-<modname>.

Let's list some history, please notify if I forgot something important.

python3 packages were introduced to epel with python3x naming
originally, and unlike fedora naming, python3 was replaced on every
package with %python3_pkgversion and related macros. When python 3.6
was introduced to epel7 there was new macro %python3_other_pkgversion
and related to that macros added.

When python 3.4 got EOL, macros were switched and python36 naming was
set for %python3_pkgversion

rhel7.7 introduced python3 with fedora style python3 naming and
%python3_pkgversion set to 3.

Now systems using new python-rpm-macros from rhel7.7 can't any more
build any python3 package because all dependencies switch from
python36-<modname> to python3-<modname> so package builds will fail
inside mock. Because of koji still using old python*rpm-macros this is
not yet visible on fedora build system but I tested and verified this
with mock. Also these new macros cause all new python packages to be
named python3-<modname>.

There are two possibilities how to handle this:

Introduce conflicting %python3_pkgversion (and other related macros)
with 36 and 3.6 etc in them.

This would cause pain in every occasion when there is new python3
package added to rhel7 because rhel7 uses different naming. That
would mean we would need to manually patch dependencies on packages in
rhel7 because we don't have any guarantee that rhel packagers remember
epel when doing rhel packages. So we need to manually change
dependencies to rhel packages to be python3, not

My suggestion for this is to do big python3 rebuild again in epel7,
this time with python3_pkgversion from rhel7.7 and move clearly to
rhel7.7 python3 naming and obsolete pythn34 now, people have already
been notified that python34 is end of the life and not supported by

Add epel specific python_provide macro which for python3-modname does:
normal provides as it did before.

Provides: python3-<modname> = %{version}-%{release}
Obsoletes: python36-<modname> < %{version}-%{release}
Obsoletes: python34-<modname> < %{version}-%{release}

Remove python3_other from epel7.

Only downside from this is that python3-modname source rpm naming won't
work any more because rpm doesn't allow python3-modname naming in
sub-package. My suggestion for that is to name these epel only
source packages with python3-epel-modname or python3-modname-epel
naming so that they can generate python3-modname.

python3_other is now defined to 3 in rhel7.7. - I wrote wrong macro name there.

What I ment to say was python3_pkgversion is now defined to 3 in rhel7.7.

Note that the python3-foo and python36-foo pakcages shoudl be totally interchangeable (as long as they use %python_prvide and get a RHEL 7.7 based rebuild).

So it can go in this order:

  1. retire the pythno34 stack
  2. packages that want to can get renamed by switching from %python3_pkgversion macro to 3 manually, cleaning up the specfile to make it more Fedora-like
  3. (if needed) remove the %python3_pkgversion redefined value from EPEL (gets defined to 3 by RHEL)

Note that some spec files will become invalid by the last step, such as if they have the following pattern:

Name: python3-foo

%package -n python%{python3_pkgversion}-foo

Giving the time frame of EPEL 7 EOL, I don't think this i wort it.

EPEL 7 EOL should happen when RHEL7 is EOL? That is some years ahead. June 30, 2024.

Mea culpa I have mixed up EPEL 6 with 7.

packages that want to can get renamed by switching from %python3_pkgversion macro to 3 manually, cleaning up the specfile to make it more Fedora-like

A big +1 to this. Some maintainers are resistant to EPEL-specific things in the master branch, so this will allow more of those to just be branched and built for epel7 as is. In fact, can we just start doing this now, separate from the python34 retirement?

pinging this for the next meeting

Python Maint is happy to help, supports the removal, but does not have free cycles to execute it.

Metadata Update from @smooge:
- Issue close_status updated to: Unable to Fix
- Issue status updated to: Closed (was: Open)

a year ago

Login to comment on this ticket.