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.)


Comments on this page:

FWIW, I upgrade my main Fedora machine by executing a disaster recovery procedure (i.e. install new release, restore package selection, restore backup etc. in an automated fashion).

I've basically ignored dnf modules so far and (fortunately) with my default package list no modules get auto-installed this way.

Looking at the available modules there isn't really anything that seems relevant to me.

Since the dnf module repositories slow down dnf update it's on my todo list to just disable the dnf module repositories (e.g. with sed 's/^enabled=1/enabled=0/' /etc/yum.repos.d/*modular* -i ).

Since dnf modules only get into your way, perhaps just disabling the dnf module repositories would make your life simpler?

as it currently stands, Fedora DNF modules are broken

Don't we know! I have several hundred emails that attest to that. :-)

The Fedora Engineering Steering Committee (FESCo) made some policy changes for IIRC Fedora 32 that should address some of these concerns. The team within Red Hat that works on Modularity has posted a [draft plan](https://fedoraproject.org/wiki/Objectives/Modularity_Improvements_2020) to make improvements in the Modularity experience for users and packagers. Fedora 33 specifically will include [fixes for the upgrade experience](https://fedoraproject.org/wiki/Changes/Module_Obsoletes_and_EOL).

By Ben Cotton at 2020-08-09 09:53:36:

And my apologies for writing in markdown instead of wiki-text and then forgetting to look at the preview :-)

By Conan Kudo (ニール・ゴンパ) at 2020-08-29 14:27:14:

You should be fine from Fedora 32 onward. There are no default-enabled modules in Fedora 32, and all the Rust software is no longer delivered with modules in Fedora 32.

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, View Normal, Add Comment.
Search:
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.