On 10. 10. 19 2:11, Nico Kadel-Garcia wrote:
On Wed, Oct 9, 2019 at 6:24 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
On 09. 10. 19 21:23, Nico Kadel-Garcia wrote:
On Oct 9, 2019, at 8:03 AM, Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
On 09. 10. 19 13:47, Nico Kadel-Garcia wrote:
It's going to be a while before EPEL gets all of the "python36"
labeled packages rebuilt to say "Provides: python3-module" as well as
"Provides: python36-module" for complete consistency with the altered
name used by RHEL. The epel-rpm-macros package sets the python modules
to set "python3_pkgversion" to be "36" instead of plain "3", and helps
find and resolve the python dependencies from the slightly older EPEL
versions. It also helps distinguish new built modules as being EPEL
based instead of merely RHEL or CentOS based.
How does epel-rpm-macros package sets the python modules to do that?
What kind of sorcery is there? AFAIk it is the %python_provide macro defined in python-rpm-macors (required by python3-devel).
It restores the python3_pkgversion to “36”, which EPEL packages expect and set requirements for.
I've just double checked and the package that sets this is indeed
epel-rpm-macros. But it is pulled to the buildroot for all epel7 builds.
I'm not happy that RHEL upstream selected to use "python3" instead of
"python36" as the package name for their release of Python 3.6. Like
modularity, it's solving one problem but generating others.
All RHEL python3 packages also provide their python36 names. Where is the problem? If there is some, how can we fix it?
Complete the reverse process. Have all EPEL python 36 modules “provide” python3-module, as well. Otherwise, building the packages with mock or koji is a bit of an adventure.
What adventure? Just BRing python%{python3_pkgversion}-foo as always worked
prior to this change and it still works afterwards.
Except that, for RHEL 7.7 and CentOS 7.7, they set python3_pkgversion
to "3". epel-rpm-macros restores it to "36", and re-enables build-time
dependency on the python36 modules that are only available from EPEL.
Fedora SRPM's have taken to listing dependencies as "python3-module",
so if you try to build a Fedora SRPM on RHEL or CentOS without doing
this "epel-rpm-macros" and replacing "python3-" with
"python%{python3_pkgversion}", you can't resolve the dependencies.
That wasn't possible before either.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 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/devel@xxxxxxxxxxxxxxxxxxxxxxx