View Issue Details

IDProjectCategoryView StatusLast Update
0017283CentOS-8generalpublic2020-04-23 22:45
Reporterjcbollinger 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
Product Version8.1.1911 
Target VersionFixed in Version 
Summary0017283: module metadata change yields brokenly mismatched python3-devel dependencies
DescriptionWithin the last couple of days, the CentOS-Stream-AppStream repository's metadata was changed to make the python38-3.8 stream a default stream. Previously, it was not a default stream. Some of the development components from that stream are concurrently installable with those with the development components for the python36-3.6 stream, and having both as default streams yields broken package combinations.

Specifically, installing python3-devel via dnf pulls in python36-devel from the python36-3.6 stream, but python38-rpm-macros from the python38-3.8 stream. I suppose that the latter is of no consequence if you are not building RPMs, but if you ARE building RPMs then, well, you're not building them any more.

This especially interferes with building RPMs via mock, because you need to perform several extra steps for every single build of a python3 RPM. After figuring out what those are, of course.
Steps To ReproduceThe metadata change can be seen by clearing dnf's cache ("dnf clean all" to be sure), reading updated metatdata (by, say "dnf update --assumeno"), and then listing the module metatdata ("dnf module list").

The package mismatch can be demonstrated several ways, but one relevant and non-destructive way is via mock:

- Install the "mock" package from EPEL-8.

- Initialize a CentOS-Stream chroot via mock:
    mock -r /etc/mock/centos-stream-x86_64.cfg --init

- Install python3-devel into the chroot:
    mock -r /etc/mock/centos-stream-x86_64.cfg --dnf-cmd install python3-devel

The output shows that mismatched packages are installed, as described. Attempting to build a python3 package in such a mock chroot immediately runs aground on the fact that the %{__python3} rpm macro names a Python interpreter that does not exist in the chroot.
Additional InformationOne can correct the mismatch described by manually installing the python36-rpm-macros package, which also automatically uninstalls the python38 counterpart. Of course, one can also manually disable the python38-3.8 stream if one know in advance to do so. But it's not so easy with mock, which intentionally pulls a clean configuration for every build -- unless you know how to wrangle it to avoid that, at least.

This does not appear to present an issue for those who already have the python3 development packages installed, because dnf seems disinclined to offer the python38 package as an update to the python36 package (as is right and proper). But it presents a trap for new installations, and it is an ongoing problem for packaging with mock, as already discussed.
Tagsmodule, module-stream, python

Activities

There are no notes attached to this issue.

Issue History

Date Modified Username Field Change
2020-04-23 22:44 jcbollinger New Issue
2020-04-23 22:44 jcbollinger Tag Attached: module
2020-04-23 22:45 jcbollinger Tag Attached: python
2020-04-23 22:45 jcbollinger Tag Attached: module-stream