Created attachment 1956646 [details] Reproducer script Description of problem: Cannot add texlive as Recommends, because it is somehow ignored by dnf. Not sure if this is an issue in texlive, but it only happens in rawhide, and only as Recommends. Version-Release number of selected component (if applicable): 2023 How reproducible: ./issue.sh rawhide # see attachment Actual results: texlive is not added to the transaction (with weak dependencies enabled). Expected results: texlive is added to the transaction, i.e., ./issue.sh 38 # this works as expected
Best guess: texlive is not added to the transaction because the binary "texlive" RPM contains no files: https://koji.fedoraproject.org/koji/rpminfo?rpmID=34114997 It only exists as a helper for people who do not know better to install "texlive-collection-latexrecommended" and "texlive-scheme-basic", which the "texlive" binary RPM Requires. That said, it should show up, so this is either a DNF or an RPM bug in Rawhide. Reassigning to DNF.
That said, please don't put "Recommends: texlive", as this is almost certainly wrong. Figure out what specific tex components you need and do: Recommends: tex(foo)
I know, I just wanted to simplify things as much as possible. You can check that these don't work either: Recommends: tex(latex) Recommends: texlive-collection-latexrecommended Change Recommends -> Requires, then it works Change rawhide -> 38, then it works
Can you tell us what version of the following packages you have in the container? I cannot reproduce it my my F39 virtual machine with these: # rpm -q dnf libdnf libsolv librepo dnf-4.15.0-1.fc39.noarch libdnf-0.70.0-1.fc39.x86_64 libsolv-0.7.22-4.fc38.x86_64 librepo-1.15.1-2.fc38.x86_64
I tried current quay.io/fedora/fedora:39 (e1de9e9e9c08) and it works for me. It contains the same DNF packages. Are you sure your YUM repository contains "texlive" package (dnf repoquery texlive)?
Argh, I thought I updated the image to the latest version, but it seems I didn't: # rpm -q dnf libdnf libsolv librepo dnf-4.14.0-1.fc38.noarch libdnf-0.68.0-1.fc38.x86_64 libsolv-0.7.22-3.fc37.x86_64 librepo-1.15.1-1.fc38.x86_64 I confirm that updating the image makes the issue disappear. Apologies for the noise.
I downgraded the DNF packages to your version and still were not able to reproduce it. It was probably caused by something else. I would suspect a (cached) content of the YUM repository.
Cached where? I was spawning a fresh container each time.
/var/cache/dnf. But a fresh container should have none. Maybe a mirror of your choice. I guess we will never know what what was the case.