2020-04-06
Fedora 31 fumbles DNF modules, package updates edition
I still run 'dnf check-update' every so often (despite what I
wrote before), and for a while it has
been reporting it had update info for 'rust-ripgrep' version 12.0.0
(aka the 'ripgrep' package),
among other updates. I have ripgrep 11.0.2 installed and use ripgrep
a fair bit, so an upgrade was (and is) of interest to me. However,
'dnf update' never offered to install such an update. Today I dug
into what is going on, and it has left me unhappy.
Modern versions of Fedora use DNF modules
(also), which
serve as the source of various programs. When you update Fedora,
at least in my way of doing it, some
number of these modules are silently enabled based on what programs
you have installed (and perhaps what versions). Modules come in
multiple versions (you can have 'the latest' and 'version X' and
so on), so my first thought was that ripgrep 12.0.0 was coming from
a version of the ripgrep module that I didn't have enabled. However,
'dnf module list' said that there was only one ripgrep module,
providing the latest version, and it was enabled (and it also only
had one profile):
ripgrep latest [d][e] default [d] [...]
I will skip to the conclusion, rather than going through my investigation steps (which involved things like looking at Bodhi and digging through a mirror of the actual Fedora updates repository). Fedora has ripgrep 12.0.0 in the main Fedora updates repository, but not in the 'ripgrep' DNF module that is supposed to have the latest version. In fact it has a number of modular packages that have been orphaned this way. On my system, all of gimp, libgit2, meson, and ripgrep have more recent versions in the main Fedora updates repository than in DNF modules.
(In libgit2's case, it appears that I somehow got locked into the libgit2 0.27 DNF module instead of the 0.28 one that is now current in Fedora's updates. Since I never explicitly chose a DNF module version, this is a problem in itself; simply having some version of libgit2 installed when DNF modularized my system shouldn't lock me into it.)
You can see what normal Fedora upgrades your DNF modules are blocking
off from you with a magic flag that is barely documented (with large
caution notes) in the dnf manpage:
dnf --setopt=updates.module_hotfixes=true check-update
Fixing this is what you would call more chancy. First, you want to
revert the DNF modules back to a state where they are neither explicitly
enabled nor explicitly disabled, with 'dnf module reset ..':
dnf module reset ripgrep libgit2 meson gimp
However, for me this by itself only unlocked the libgit2 package upgrades (after I did 'dnf clean metadata'). To upgrade the other packages, I had to resort to that dangerous dnf magic option again:
dnf --setopt=updates.module_hotfixes=true update
Because I am a cautious person, I re-ran the check-update command with the 'fedora' repository also overriding modules, which revealed that even from the moment Fedora 31 was released, some modules were behind the main versions. I started out fixing only the ninja-build package ('1.9.0-1' in its module, '1.9.0-3' in the Fedora 31 release repository) but wound up fixing all of them, which wound up with me having no DNF modules enabled at all and no RPMs installed from them. If you want to fix everything all at once, you want:
dnf --setopt=updates.module_hotfixes=true --setopt=fedora.module_hotfixes=true update
As a nice change, 'dnf updateinfo info' now has nothing to report, as
I expect it to be on a fully up to date system.
(Sadly I suspect several of these DNF modules will magically spring back to life when I upgrade to Fedora 32, and I will have to go fix them all again.)
(This elaborates on some tweets.)