On Tue, 2023-05-30 at 11:08 +1000, Ian Laurie wrote:

I usually run DNF via an automation script of mine, and I noticed it complained there was no /etc/dnf/dnf.conf file available (my script checks it and warns if there are active excludes in it).

My dnf.conf had become dnf.conf.rpmnew which is why my automation script complained. However /usr/bin/dnf was still pointing at dnf-3, not dnf5.

So it disabled my config for dnf-3 but didn't migrate me over all the way to dnf5?

Should I manually point the dnf link to dnf5?

As a separate issue, I do have an active exclude (coreutils, pending a revert of a recent change that introduced an undesirable feature). Where does one put the "exclude=coreutils" in a dnf5 world? Note right now I don't have a functioning /etc/dnf/dnf.conf file (it got renamed to dot rpmnew)

This was an issue for one day's compose only, because we untagged the 'new default' dnf5 (because it caused problems) but didn't also untag the dnf (4) update that went with it, dropping some files so that dnf5 could provide them instead.

Today's compose should already have the older dnf package back.

Fri May 26 02:10:59 2023 dnf-4.16.0-1.fc39 tagged into f39 by bodhi Sun May 28 21:53:53 2023 dnf-4.16.0-1.fc39 untagged from f39 by kevin

It sounds like you got 4.16.0-1.fc39, so you should manually downgrade to dnf-4.15.1-1.fc39 , and maybe put that config file back.