On 09. 10. 19 21:23, Nico Kadel-Garcia wrote:
> On Oct 9, 2019, at 8:03 AM, Miro Hrončok
<mhroncok(a)redhat.com> 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.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok