The dnf module list command is not producing the correct output on fedora 39？

Ask Fedora
, ,
1

On Fedora 39, executing the dnf module list command does not produce any output.

Previously on Fedora 38, this command worked correctly. For example, to view the available streams of the PostgreSQL module, I could use dnf module list postgresql to list the available streams of the PostgreSQL module.

$ dnf module list postgresql
Fedora Modular 37 - aarch64
Name                      Stream               Profiles                     Summary
postgresql                12                   client, server               PostgreSQL module
postgresql                13                   client, server               PostgreSQL module
postgresql                14                   client, server               PostgreSQL module
postgresql                15                   client, server               PostgreSQL module
Fedora Modular 37 - aarch64 - Updates
Name                      Stream               Profiles                     Summary
postgresql                12                   client, server               PostgreSQL module
postgresql                13                   client, server               PostgreSQL module
postgresql                14                   client, server               PostgreSQL module
postgresql                15                   client, server               PostgreSQL module
Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled

However, when I execute it on Fedora 39, there is no output. Why is this happening?

$ sudo dnf module list
Last metadata expiration check: 0:21:49 ago on Mon 11 Dec 2023 01:02:34 AM CST.

$ sudo dnf module info postgresql
Last metadata expiration check: 0:21:53 ago on Mon 11 Dec 2023 01:02:34 AM CST.
Unable to resolve argument postgresql
Error: No matching Modules to list

I have tried the following methods to fix the issue, but none of them worked. Why is the dnf module list command not functioning?

DNF Cache Issues

It could be due to outdated or corrupted metadata cache of DNF. Try clearing the cache and resynchronizing the repository information:

$ sudo dnf clean all
$ sudo dnf makecache

System Updates

If your system has not been updated for a long time, you might need to update it first:

$ sudo dnf update

Host Info

$ hostnamectl
     Static hostname: fedora39-bin
     Pretty hostname: dev-env-bin
           Icon name: computer-vm
             Chassis: vm 🖴
          Machine ID: f2e1fc6f47d8484ba3804011f0bd423f
             Boot ID: db317976494441638c4fbe44792128e2
      Virtualization: parallels
    Operating System: Fedora Linux 39 (Workstation Edition)
         CPE OS Name: cpe:/o:fedoraproject:fedora:39
      OS Support End: Tue 2024-11-12
OS Support Remaining: 11month 1d
              Kernel: Linux 6.6.4-200.fc39.aarch64
        Architecture: arm64
     Hardware Vendor: Parallels International GmbH.
      Hardware Model: Parallels ARM Virtual Machine
    Firmware Version: 19.1.1 (54734)
1 Like
2

As I understand it, with fedora 39 the use of modules has been 100% discontinued and removed. The only modules you may still have installed would be relics from an earlier version that had been upgraded.

Even the ‘modular’ repo files have been removed from /etc/yum.repos.d/

If I understand correctly the dependencies of the rpms handle everything that was initially intended with the modular repos and the work load and complexity of supporting modular package distribution was not economical nor sustainable.

4 Likes
3

I’m really sorry to hear that. How can I check which versions of PostgreSQL are available for installation on Fedora？

In Fedora, the command sudo dnf module list postgresql is specifically used to list the available PostgreSQL modules and their versions (streams). If I want to achieve a similar effect without using the module command, the options are limited, as Fedora’s modular system provides a unique way to manage software package versions.

Use dnf search to Find PostgreSQL Packages

This command will display all packages related to PostgreSQL, but it might not provide the same detailed version information as the module command.

1 Like
4

dnf info <packagename> provides info about the packages. Using dnf to perform an upgrade will always upgrade to the latest versions available, but that can be controlled by excluding packages that you do not want to upgrade.

Database packages are ones that rightfully should not be just upgraded on a whim since changes may break apps using those databases. On fedora 39 the only version of postgresql I find is 15.4 which is the one it was released with.

5

Thank you very much for your reply.

6

Edit: removed bad change link, Chris posted the correct one.

7

That’s the wrong change:

Note: this Change was effectively extended and superseded by Changes/RetireModularity.

2 Likes
8

As far as I understand though, there would be no older supported versions. E.g. single supported ruby version. If there was an older version, then it will not receive updates. dnf update will update it without asking, etc.

So there is no replacement of the feature in fact, correct?

9

dnf update does stop, display the changes suggested, and ask for confirmation. dnf update -y has already been given permission to continue so it does not stop and ask (it still displays the suggested changes).

10

pls don’t pick on wording issues. The point was that previously you could get a specific version that will receive point updates. Now you surely can lock version but then you get no updates or if you don’t lock, you get upgraded to an unknown version. One can’t usually keep track of all updates going on. Functionality was not replaced, it was removed. Which might be valid given the cost/benefit analysis. But lets not pretend everything is like before.

11

I’m not clear what you are saying has been removed.
For ruby it seems that only one version was ever supported.

But, for example, many python versions are support and installable side-by-side.
This is becuase the maintainers are willing to put in the work to support multiple versions.

12

Then maybe I’m mistaken and think about RHEL supporting multiple versions with module. It seems to me that it would be a mess though to support multiple ruby versions without modules.

13

I have seen multiple ruby on rhel using modules.
Fedora dropped modules as it was not working at all well in the Fedora world.