More problems with Fedora 31 DNF modules and package updates

August 8, 2020

A while back I wrote about how Fedora 31 had fumbled DNF modules and package updates, which ended with me believing that I had fixed the problem so that I would get updates to packages I cared about despite the DNF module versions not being updated. Then recently I tweeted:

It turns out that Fedora 31 DNF modules, even reset ones that aren't active, are apparently still both out of date and blocking package updates. Modular ripgrep is 11.x, current main repo ripgrep is 12.1.0, but good luck getting that.

Dear Fedora: If I have to resort to bodhi to get the latest stable main repository version of packages, DNF has failed *spectacularly*. If these packages had security updates, there would be real issues here.

As before, for a while 'dnf updateinfo info' has been telling me that there was an update to ripgrep available, to 12.1.0 (I had 12.0.0). However I couldn't get dnf to actually apply the update, and the latest version that the 'ripgrep' module has is 11.0.2. Similar problems were reported for meson and a couple of other packages. This is despite the fact that I had no DNF modules enabled; I had reset all of them in my first go around.

To actually get the current packages, I resorted to the brute force approach of downloading them through bodhi. This is not an approach that most people can do (most people aren't even aware of Bodhi). Looking back, it's possible that I could have succeeded by using the set of command line options from my first entry. I didn't think of trying it at the time, and anyway I knew that Bodhi would work for sure and I had already wasted enough time (and accumulated enough frustration on Fedora DNF's broken modularity).

Allow me to emphasize that: as it currently stands, Fedora DNF modules are broken. Module packages are not being kept up to date (even when the module claims to be the 'latest' version of a program) and the mere existence of modules blocks you from getting up to date packages from the main repository. If I could completely remove or turn off DNF modules, I would, but as far as I know they're deeply integrated into DNF and aren't optional in that way.

After I went through the Bodhi approach I hunted around and found an assortment of files in /etc/dnf/modules.d, which appears to be where DNF records modules you've done anything at all with. There were files lingering here for every DNF module I'd ever had enabled, even if I'd done 'dnf module reset ..' on them. I removed all of these files, so maybe the next time there's a new ripgrep update I'll get it without any hassles.

(I know, I have to update to Fedora 32 sometime, which is going to re-enable various modules that I'll have to clean out again. I haven't gotten around to it the way I usually do because all of my usual processes for this have been thrown off by working from home all of the time due to ongoing world and local events.)

Written on 08 August 2020.
« How we choose our time intervals in our Grafana dashboards
Unix options conventions are just that, which makes them products of culture »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Aug 8 23:41:39 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.