[CentOS-devel] centos-7.7 or centos-cr brakages building python3 packages with EPEL enabled

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!