I've started testing with the "cr" repositorory enabled, and we are going to have a *lot* of problems building EPEL packages unless we get well ahead of the game.
RHEl has elected to publish their python3 modules as "python3-module", and to obsolete "python36-module" names. All well and good, this will help provide upgrade paths from EPEL. The problem is that they've also updated "pythone_pkgversion" to be "3", instead of "36". And every package that uses "python%{python3_pkgversion} is going to break if the package is published as an EPEL package, such asl "python36-pylint", and is not available as a "python3-pylint" package.
It's potentially soluble by every single EPEL package being updated to "Provide:" python3-module, as well as python36-module. But then that gets into the "we never, never, never overlap with RHEL published packages". So the technological fix that allows Red Hat to Obsolete: the EPEL versions, as they just did with "python3" obsoleting ade past and over packages as they just die, with "python3-devel" and "python3-devel", is going to have to be done with almost every python EPEL package and those packages ingested into the RHEL upstream repository.
I'm not sure where to best resolve this. I ran into it while trying to update a "mock" SRPM with the "cr" repository enabled, and savagery ensued with dependencies on "python3-pylint", for which there is not EPEL or CentOS package.
On Sun, Sep 15, 2019 at 9:12 PM Nico Kadel-Garcia nkadel@gmail.com wrote:
I've started testing with the "cr" repositorory enabled, and we are going to have a *lot* of problems building EPEL packages unless we get well ahead of the game.
RHEl has elected to publish their python3 modules as "python3-module", and to obsolete "python36-module" names. All well and good, this will help provide upgrade paths from EPEL. The problem is that they've also updated "pythone_pkgversion" to be "3", instead of "36". And every package that uses "python%{python3_pkgversion} is going to break if the package is published as an EPEL package, such asl "python36-pylint", and is not available as a "python3-pylint" package.
It's potentially soluble by every single EPEL package being updated to "Provide:" python3-module, as well as python36-module. But then that gets into the "we never, never, never overlap with RHEL published packages". So the technological fix that allows Red Hat to Obsolete: the EPEL versions, as they just did with "python3" obsoleting ade past and over packages as they just die, with "python3-devel" and "python3-devel", is going to have to be done with almost every python EPEL package and those packages ingested into the RHEL upstream repository.
I'm not sure where to best resolve this. I ran into it while trying to update a "mock" SRPM with the "cr" repository enabled, and savagery ensued with dependencies on "python3-pylint", for which there is not EPEL or CentOS package.
epel-rpm-macros has already overridden %python3_pkgversion. If you want the override locally, just install that package into your environment.
On Sun, Sep 15, 2019 at 9:17 PM Neal Gompa ngompa13@gmail.com wrote:
epel-rpm-macros has already overridden %python3_pkgversion. If you want the override locally, just install that package into your environment.
Good, thanks. It looks like that is going to be necessary in /etc/mock/epel-7-*.cfg for the foreseeable futures.
-
Neal Gompa -
Nico Kadel-Garcia