View Issue Details
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 | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | always |
Status | new | Resolution | open | ||
Product Version | 8.1.1911 | ||||
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 |