On 12. 08. 19 8:14, Tuomo Soini wrote:
On Sun, 11 Aug 2019 22:26:45 +0200
Miro Hrončok <mhroncok(a)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.
By what? Do you mean python3_pkgversion? W can override that as well.
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
There are two possibilities how to handle this:
Introduce conflicting %python3_pkgversion (and other related macros)
with 36 and 3.6 etc in them.
Let's do that as a quick hotfix for now decide the rest later.