V Thu, May 16, 2024 at 04:29:21AM -0600, Neal Gompa napsal(a): > On Thu, May 16, 2024 at 3:10 AM Fabio Valentini <decatho...@gmail.com> wrote: > > > > On Thu, May 16, 2024 at 9:25 AM Zbigniew Jędrzejewski-Szmek > > <zbys...@in.waw.pl> wrote: > > > > > > Hi, > > > > > > I've been trying to get 'add-determinism' deployed in buildroots. This > > > has been unsuccessful because of the following issue. > > > > > > The dependency chain is: > > > redhat-rpm-config has > > > Requires build-reproducibility-srpm-macros > > > and build-reproducibility-srpm-macros has > > > Requires: (add-determinism if python3-libs else > > > add-determinism-nopython) > > > Suggests: add-determinism-nopython > > > > > > (The idea is that we install 'add-determinism-nopython' which is > > > self-contained, > > > but if python3 is installed into the buildroot, we pull in the heavier > > > version > > > which has a dependency on python3-libs.) > > > > > > This works well enough when installing packages using dnf on a test > > > system. > > > But, in koji and mock builds, this results in rpm-build being unistalled > > > (!). > > > > > > For example, see > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=117684626 > > > and root.log there: first rpm-build is installed along with a bunch of > > > other > > > packages expected in the buildroot, but then cargo-rpm-macros is requested > > > (presumably via %generate_buildrequires), which depends on python3 and > > > python3-libs. > > > > > > Dnf5 realizes that to satisfy all bounds, it can either: > > > a) install cargo-rpm-macros, python3, python3-libs, add-determinism, and > > > remove add-determinism-nopython > > > b) install cargo-rpm-macros, python3, python3-libs, and remove > > > build-reproducibility-srpm-macros, > > > rpm-build, fonts-srpm-macros, redhat-rpm-config, and a few other > > > packages. > > > and picks option b). > > > > This looks like you're putting the resolver between a rock and a hard > > place. :thinking: > > I don't think I've ever seen packages being *removed* when installing > > BuildRequires on top of the minimal buildroot ... > > > > Would it be possible to adapt the packages so that add-determinism and > > add-determinism-nopython are parallel-installable, and have the macro > > fall back to the add-determinism-nopython executable if the > > add-determinism executable is not available? > > That way BuildRequires are additive and wouldn't force package removal > > from the buildroot, and the rich dependency could be simpler - i.e. > > `Requires: (add-determinism if python3-libs)`, without Suggests or > > else branch. > > I have the question of why is dnf5 running as if "--allow-erasing" is > always passed to it? Older versions of DNF explicitly didn't do that > because we get weird behaviors like this. > It's running as if --allow-erasing is passed because --allow-erasing was passed:
DEBUG util.py:558: Executing command: ['/usr/bin/systemd-nspawn', '-q', '-M',
'de96c7c84e6d430584a7795d75824e1d', '-D',
'/var/lib/mock/f41-build-50967284-6084889-bootstrap/root', '-a',
'--capability=cap_ipc_lock',
'--bind=/tmp/mock-resolv.1old43uf:/etc/resolv.conf', '--console=pipe',
'--setenv=TERM=vt100', '--setenv=SHELL=/bin/bash',
'--setenv=HOME=/var/lib/mock/f41-build-50967284-6084889/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/dnf5',
'builddep', '--installroot', '/var/lib/mock/f41-build-50967284-6084889/root/',
'/var/lib/mock/f41-build-50967284-6084889/root//builddir/build/SRPMS/rust-proc-macro2-diagnostics-0.10.1-1.fc41.src.rpm',
'--setopt=deltarpm=False', '--setopt=allow_vendor_change=yes',
'--allowerasing', '--setopt=tsflags=nocontexts'] with env {'TERM': 'vt100',
'SHELL': '/bin/bash', 'HOME':
'/var/lib/mock/f41-build-50967284-6084889/root/installation-homedir',
'HOSTNAME': 'mock', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND':
'printf "\\033]0;<mock-chroot>\\007"', 'PS1': '<mock-chroot> \\s-\\v\\$ ',
'LANG': 'C.UTF-8', 'LC_MESSAGES': 'C.UTF-8', 'SYSTEMD_NSPAWN_TMPFS_TMP': '0',
'SYSTEMD_SECCOMP': '0'} and shell False
DEBUG util.py:463: Updating and loading repositories:
DEBUG util.py:463: build 100% | 118.4 KiB/s
| 3.8 KiB | 00m00s
DEBUG util.py:463: Repositories loaded.
DEBUG util.py:463: Package Arch Version
Repository Size
DEBUG util.py:463: Removing dependent packages:
DEBUG util.py:463: build-reproducibility-srpm-macros noarch 0.2.0-6.fc41
build 684.0 B
DEBUG util.py:463: fonts-srpm-macros noarch 1:2.0.5-14.fc40
build 55.3 KiB
DEBUG util.py:463: forge-srpm-macros noarch 0.3.1-1.fc41
build 39.0 KiB
DEBUG util.py:463: go-srpm-macros noarch 3.6.0-1.fc41
build 60.8 KiB
DEBUG util.py:463: python-srpm-macros noarch 3.12-9.fc41
build 50.5 KiB
DEBUG util.py:463: redhat-rpm-config noarch 289-1.fc41
build 183.5 KiB
DEBUG util.py:463: rpm-build x86_64 4.19.1.1-2.fc41
build 173.7 KiB
The reason why builddep is invoked with --allow-erasing is building packages
whose dependencies are alternatives to packages of a default version and thus
conflicts with them. In these cases you need uninstall conflicting packages.
A workaround could be rpm-build or mock to register rpm-build package in
/etc/dnf/protected.d configuration files. Packages listed there are prevented
from removal no matter of --allow-erasing.
Proper solution is actually minimazing content of the minimal build root, or
if not possible, then making the packages nonconficting. In ideal world
--allow-erasing would not be needed because the minimal build root would only
contain packages essential for everybody.
-- Petr
signature.asc
Description: PGP signature
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
