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.