When working on a set of related packages, I'll often build some package locally in mock, install it in the mock, and then build dependent packages with 'mock -n'. I *think* this used to work. But now, mock/dnf/something causes all packages that are available in the distro to be reinstalled with the distro version. This applies to anything listed in BuildRequires or produced via %generate_buildrequires. The package that is already installed can have the same or higher version, it is still reinstalled. Example: $ mock -r fedora-rawhide-x86_64 --shell 'rpm -q python3-tables' python3-tables-3.7.0-9.fc39.x86_64 $ git grep tables *spec python-dask.spec:BuildRequires: python3dist(tables) $ fedpkg srpm && mock -r fedora-rawhide-x86_64 -n $(ls -1tr *.src.rpm |tail -n1) ... ERROR: Command failed: # /usr/bin/systemd-nspawn -q -M 8154e509100442fda380e1c1e903b8e8 -D /var/lib/mock/fedora-rawhide-x86_64-bootstrap/root -a --capability=cap_ipc_lock --bind=/tmp/mock-resolv.otmy5twh:/etc/resolv.conf --console=pipe --setenv=TERM=vt100 --setenv=SHELL=/bin/bash --setenv=HOME=/var/lib/mock/fedora-rawhide-x86_64/root/installation-homedir --setenv=HOSTNAME=mock --setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin --setenv=PROMPT_COMMAND=printf "\033]0;<mock-chroot>\007" --setenv=PS1=<mock-chroot> \s-\v\$ --setenv=LANG=C.UTF-8 --setenv=LC_MESSAGES=C.UTF-8 --resolv-conf=off /usr/bin/dnf-3 builddep --installroot /var/lib/mock/fedora-rawhide-x86_64/root/ --releasever 39 --setopt=deltarpm=False --allowerasing --disableplugin=local --disableplugin=spacewalk --disableplugin=versionlock /var/lib/mock/fedora-rawhide-x86_64/root//builddir/build/SRPMS/python-dask-2023.4.1-4.fc39~bootstrap.src.rpm No matches found for the following disable plugin patterns: local, spacewalk, versionlock fedora 23 kB/s | 17 kB 00:00 Last metadata expiration check: 0:00:01 ago on Wed Jul 19 12:14:58 2023. Package python3-devel-3.12.0~b4-1.fc39.x86_64 is already installed. Package python3-fastavro-1.7.4-2.fc39.x86_64 is already installed. Package python3-graphviz-1:0.20.1-3.fc39.noarch is already installed. Package python3-h5py-3.8.0-3.fc39.x86_64 is already installed. Package python3-ipython-8.14.0-4.fc39.noarch is already installed. Package python3-psutil-5.9.2-3.fc39.x86_64 is already installed. Package python3-pyarrow-12.0.1-3.fc39.x86_64 is already installed. Package python3-requests-2.28.2-4.fc39.noarch is already installed. Package python3-sqlalchemy-1.4.49-1.fc39.x86_64 is already installed. Package python3-zarr-2.14.2-2.fc39.noarch is already installed. (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) Error: Problem: conflicting requests - nothing provides python3.11dist(packaging) needed by python3-tables-3.7.0-7.fc38.x86_64 - nothing provides python(abi) = 3.11 needed by python3-tables-3.7.0-7.fc38.x86_64 - nothing provides python3.11dist(numpy) >= 1.19 needed by python3-tables-3.7.0-7.fc38.x86_64 - nothing provides python3.11dist(numexpr) >= 2.6.2 needed by python3-tables-3.7.0-7.fc38.x86_64 mock-4.1-1.fc38.noarch rpm-4.18.1-3.fc38.x86_64 dnf-4.16.1-1.fc38.noarch Dunno, maybe it's some local configuration change, but this behaviour doesn't seem very useful. Reproducible: Always
(If I comment out the BuildRequires and %generate_buildrequires sections in python-dask.spec, the package builds fine.)
Thank you for the report, Zbyszek. I finally got to this report, sorry for the delay. > I *think* this used to work Indeed, and I'd say it actually works even now. I'm curious if some package in the transaction enforces downgrade of python3-tables? I failed to reproduce this with a set of dummy packages (tested with Mock 5.1.1, currently in updates-testing) $ mock --postinstall -r fedora-rawhide-x86_64 spax-1.7-1.src.rpm $ mock -r fedora-rawhide-x86_64 -n dummy-pkg-20230920_0901-1.src.rpm ... Package spax-1.7-1.fc40.x86_64 is already installed. Dependencies resolved. ... Finish: run Is this still affecting python-tables? I tried to build the package, but after ~30 minutes I stopped waiting and started experimenting with dummy packages: https://download.copr.fedorainfracloud.org/archive/issues/mock-rhbz-2223937/
Yeah, I cannot reproduce the issue anymore. > Indeed, and I'd say it actually works even now. I'm curious if some > package in the transaction enforces downgrade of python3-tables? I guess that's the most likely explanation. What I should have done was check manually that all the packages listed by BuildRequires/%generate_buildrequires are installed in the chroot. But I didn't think of this. Let's close this. It seems to have been some transient problem.