0017283: module metadata change yields brokenly mismatched python3-devel dependencies - CentOS Bug Tracker

ID	Project	Category	View Status	Date Submitted	Last Update

0017283	CentOS-8	general	public	2020-04-23 22:44	2020-04-23 22:45

Reporter	jcbollinger
Priority	normal	Severity	minor	Reproducibility	always
Status	new	Resolution	open
Product Version	8.1.1911
Target Version		Fixed in Version

Summary	0017283: module metadata change yields brokenly mismatched python3-devel dependencies
Description	Within 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 Reproduce	The 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 Information	One 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.
Tags	module, module-stream, python

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