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.