On Sun, Sep 15, 2019 at 9:12 PM Nico Kadel-Garcia <nkadel at 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. -- 真実はいつも一つ！/ Always, there's only one truth!