[CentOS-devel] RHEL 8, and potentially CentOS 8, lack "/usr/bin/python"

On Mon, May 13, 2019 at 3:54 PM Jonathan Billings <billings at negate.org> wrote:
>
> On Mon, May 13, 2019 at 02:07:42PM -0400, Nico Kadel-Garcia wrote:
> > This "rename packages as platform-package" name seems confusing and
> > unnecessary. If that kind of reference to "platform" versions were
> > needed, perhaps it should have been published as a metapackage, with
> > "platform-python" empty except for "Includes: python3". As it is, it
> > seems merely confusing and in conflict with 20 years of Red Hat
> > package naming convention.
>
> The idea is that you never use the platform-package python at all.
> It's part of the OS, used for internal tools like dnf, and not in the
> standard path.

I see your point. I also realize I'm late to the party, and this is
already a done deal.

Unfortunately, they're not reliably distinct from the mainline python.
Packages such as "platform-python-coverage" deposit their contents in
/usr/lib64/python3.6/site-packages/coverage/. They do use
"%python_provide" in their .spec file, so they get a stack of
"Provides: python3dist(coverage)" and similar results. But this is not
backwards compatible to older RHEL releases. And because the name of
these "platform-party" packages does not even match the package name
of the SRPM, well, it gets confusing to cross-index them. It could be
really useful if the SRPM for python-coverage, which provided the
default version of the coverage module, would add this line:

     Provides: python%{python3_pkgversion}-coverage

This would be more consistent with the older package naming schemes,
and more backwards compatible. I'd welcome thoughts as to whether this
is a good idea to encourage from our upstream python packages for
these "platform" components.

python3-pip, and platform-party-pip, is even more hilarious. The
actual pip modules are from platform-party-pip. The binaries in
/usr/bin/ are from python3-pip.

> This will stop people from trying to use pip to upgrade the python
> modules used to run the package manager and break updates, for
> example.

That is a distinct issue. I've personally encountered it in full
destructive force. I've personally published.... 300 SRPMs for various
public and private repos? All to avoid just the random update issues
of pip. I used to do that for cpan published perl packages, too. But
that is a very distinct issue. Since "pip-3 install" now puts the
modules in /usr/local/lib/python3.6/, I think that this alternative
and effective solution has already solved most of *that* problem.
Would you agree that it has to do with the default python module
installation locations, and segregating critical system python tools
from looking in those locations rather than in the system default
locations?

> For packages any other package, you'd use the appstream pythons in
> your dependencies.  Its best you just treat the internal python as a
> black box and not something you actually package against.

Except..... there is no "appstream" package for the python3-coverage
module. And trying to build a python3-coverage module shows that it
would conflict with the platform-party-coverage module.

Maybe I found the one really awkward module? It wouldn't be the first
time I found the edge case early in testing.