On Sun, 11 Aug 2019 22:26:45 +0200 Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > %python3_other_pkgversion 34 > > I believe the easiest fix is to define that directly in > epel-rpm-macros: > > https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/5 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 more. 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 python%{python3_pkgversion}. 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 upstream. 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. -- Tuomo Soini <tis@xxxxxxxxx> Foobar Linux services +358 40 5240030 Foobar Oy <https://foobar.fi/> _______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
