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.
I've run full force into this with backporting things like updated
releases of awscli.
_______________________________________________
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
