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 <decathorpe@xxxxxxxxx> wrote: > > > > On Thu, May 16, 2024 at 9:25 AM Zbigniew Jędrzejewski-Szmek > > <zbyszek@xxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue