dnf 4.16.1-2
dnf5 5.0.14-1
repoquery --file
optionrepoquery --arch
optionrepoquery --installonly
optionrepoquery --extras
, --upgrades
and --recent
optionsrepoquery --changelogs
formatting optionrepoquery
download
--downloadonly
is used--downloadonly
option to multiple commandsdnf
and yum
binariesdistro-sync --skip-unavailable
downgrade --skip-unavailable
upgrade --skip-unavailable
--files
and files
querytag instead of --list
repoquery --querytags
optionrepoquery --queryformat
repoquery --qf
alias to repoquery --queryformat
dnf5 clean packages
command.remove
command accepts remove spec
group list
outputcopr
plugin commandbuilddep
plugin commandmicrodnf 3.10.0-2
Updates may require up to 24 hours to propagate to mirrors. If the following command doesn't work, please retry later:
sudo dnf upgrade --refresh --advisory=FEDORA-2023-69dfac15db
Please login to add feedback.
0 | 0 | Test Case base update cli |
0 | 0 | Test Case default font installation |
0 | 0 | Test Case langpacks packages |
0 | 0 | Test Case package install remove |
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'ignored'.
This update has been submitted for stable by bodhi
This broke openQA tests in two ways: they use
dnf groupinstall
(which dnf4 was fine with but dnf5 rejects), and they usednf config-manager --set-disabled
(which dnf5 does not seem to have implemented yet). The first is easy to address (by changing togroup install
, which fortunately dnf4 also supports), the second is harder (I'm hoping I can bodge it withsed
commands).Regarding
config-manager
, I am adding our tracking issue here for cross-reference. https://github.com/rpm-software-management/dnf5/issues/405. We will re-discuss the priority for this feature.Interestingly, I can use dnf to upgrade to this, but dnf5 fails with:
@orion I was trying to test your use case, but it seems that there is currently some issue with checking out this advisory, because the mentioned "How to install" command doesn't really do anything. I've tried it on my local machine, Rawhide VM and ask my colleague with same results...
I guess it might by connected with untagging the previous dnf-4.16.0 release from the Rawhide which was delivered to ensure unprotecting the dnf package before dnf5 replacement will come.
I've created an upstream issue for everything related to this bodhi update: https://github.com/rpm-software-management/dnf5/issues/635. Please discuss here if it is possible, thanks!
The "how to install" instructions don't really work on Rawhide, I don't think. We should probably suppress them from being displayed for Rawhide updates (or display something more accurate). I'll see if I can send a patch for that.
For Rawhide, your options are "wait for it to be pushed stable and get in a compose", "pull it from Koji manually", or "configure and temporarily enable the Rawhide buildroot repo and get it from there".
ahh, so Bodhi is set to only show the instructions for Rawhide updates once they're stable, which makes sense - but there's still a time gap between a Rawhide update being 'pushed stable' and actually reaching a compose and the compose being synced out, which is when the command will work. Not sure it's worth trying to tweak that, though.
Oh, right. So it is that confusing "after stable gap" again :) No worry, I'll just wait until it's actually in compose.
/var/lib/libdnf5 is not owned by any package but unused /var/lib/libdnf is owned by libdnf5
/var/cache/libdnf5 is not owned by any package but unused /var/cache/libdnf is owned by libdnf5
libdfn5 installs /etc/dnf/dnf.conf but not owns /etc/dnf/
@nucleo Thanks for the report! I guess the only issue there is the /var/cache/libdnf5 ownership which is fixed already in upstream. /etc/dnf is owned by dnf-data which is required by dnf5. /var/lib/libdnf5 is not used anymore, /usr/lib64/libdnf5 is owned by dnf5 now.
@orion I reproduced it having the dnf 4.15.1 and dnf5 5.0.11 in Rawhide. dnf upgrade then could be performed, while dnf5 is throwing the mentioned error. It seems to be connected with changes in handling of the protected packages in dnf and dnf5. Not sure we can do anything about it, but it should be working using the default dnf version at the time ...