$ dnf --installed list dnf | sed 1d
dnf.noarch                        4.14.0-1.fc37                        @anaconda

Hello. Unlike dnf list that presents installed and available packages with respective relevant mentions –Installed packages, Available packages–, dnf rq --all does not, nor does the switches --installed and --available combined.

Though the tags from_repo and installtime are able to display values as they are meant to with a such combination. As a consequence, installed and available packages can then be determined in outputs.

$ dnf -q rq --archlist noarch,x86_64 --installed --available --qf '%{name} %{epoch}:%{version} %{reponame} %{from_repo} %{installtime}' dnf* | head -4
dnf 0:4.14.0 @System anaconda 2022-11-05 08:51
dnf 0:4.14.0 fedora
dnf 0:4.14.0 updates-testing
dnf-automatic 0:4.14.0 fedora

When it comes to --all in place of a such combination, the tags from_repo and installtime are not able to display values as they are meant to.

Hello. Numbers of installed packages reported in total by rpm and dnf differ from each other.

$ rpm -qa | wc -l
1991
$ dnf rq --installed | wc -l
1989

I found that dnf-reposync can not fully sync packages with some repos, such as epel.
For example: I can use dnf download rpmconf-base to download rpmconf-base， but can not do dnf reposync rpmconf-base.

Dnf is very slow in terminal operation (list,search,info,etc...) because of before any commands it update itself package cache.

Therefore, we need add feature about update scheme: update cache only at background, and at CLI run commands without update. In this case, user can update cache only executing command 'makecache' or other, more suitable for this.

Also, we need avoid dnf lock when cache updates in foreground and user wants execute dnf command in same time. We can reach more closely to it with next process: downloading cache to temporary folder -> check cache independently from main cache -> locks dnf -> replace main cache -> unlocks dnf

The manpage says,

If given a command name then only displays help for that particular command

Although it provide help for a <command>, but by including "General DNF options" in the output of all dnf help <command>, it clutters the output.

I propose that "General DNF options" should not be included in the output of dnf help <command>

v. 4.14.0 | Hello. Tags provides, requires, obsoletes and conflicts lack headers associated to them in output. As a consequence when several of theses tags are part of a command, the identifications of tags represented by each string are impossible, which is the solely purpose of the existence of these tags.

$ dnf rq --installed autocorr-en --qf '%{name} %{from_repo} %{provides} %{requires} %{obsoletes} %{conflicts}'
autocorr-en fedora autocorr-en = 1:7.5.1.2-2.fc38 rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsZstd) <= 5.4.18-1 

In order to make an identification of a tag represented possible, a such tag alone has currently to be part of a command. Here is a query that makes possible the identification of tag requires as the one responsible for the dnf rq --installed autocorr-en --qf '%{name} %{from_repo} %{provides} %{requires} %{obsoletes} %{conflicts}' output.

$ dnf rq --installed autocorr-en --qf '%{name} %{requires}'
autocorr-en rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsZstd) <= 5.4.18-1

Obviously a relevant output would have exhibited tags' respective headers.
In that context that would be as follows:

$ dnf rq --installed autocorr-en --qf '%{name} %{requires}'
- Required:
autocorr-en rpmlib(CompressedFileNames) <= 3.0.4-1
(...)

question

[root@localhost ~]# dnf group install gnome-desktop
Last metadata expiration check: 1:33:01 ago on Tue 10 Jan 2023 03:58:29 PM CST.
No match for group package "gvfs-gphoto2"
No match for group package "gnome-packagekit-updater"
No match for group package "gvfs-fuse"
No match for group package "gvfs-goa"
No match for group package "fprintd-pam"
No match for group package "firewall-config"
No match for group package "gnome-classic-session"
No match for group package "gvfs-smb"
No match for group package "gvfs-afp"
No match for group package "libproxy-mozjs"
No match for group package "evince-nautilus"
No match for group package "PackageKit-gtk3-module"
No match for group package "gvfs-afc"
No match for group package "gnome-terminal-nautilus"
No match for group package "gnome-session-xsession"
No match for group package "control-center"
No match for group package "gnome-tweak-tool"
No match for group package "gvfs-archive"
No match for group package "initial-setup-gui"
No match for group package "gvfs-mtp"
Dependencies resolved.
...
[root@localhost ~]# dnf --version
4.2.23

description

Taking gnome-tweak-tool as an example, the description is as follows：

The gnome-tweaks provides the gnome-tweak-tool，unable to resolve the provider of symbol by installing gnome-tweak-tool through group, but dnf install can do it.

[root@localhost ~]# dnf install gnome-tweak-tool
Last metadata expiration check: 1:38:15 ago on Tue 10 Jan 2023 03:58:29 PM CST.
Dependencies resolved.
========================================================================================================================================================================================================================================
 Package                                                           Architecture                                      Version                                                     Repository                                        Size
========================================================================================================================================================================================================================================
Installing:
 gnome-tweaks                                                      noarch                                            3.30.2-2.hs1                                                cdrom                                            345 k
Installing dependencies:
 gnome-menus                                                       x86_64                                            3.13.3-12.hs1                                               cdrom                                            168 k
 gnome-shell-extensions                                            noarch                                            3.30.1-2.hs1                                                cdrom                                            206 k

Transaction Summary
========================================================================================================================================================================================================================================
Install  3 Packages

Total size: 719 k
Installed size: 3.0 M
Is this ok [y/N]:

Currently the usage message line of dnf help <command is a long string, e.g. for remove it is (line number added)

 1 usage: dnf remove [-c [config file]] [-q] [-v] [--version] [--installroot [path]]
 2                   [--nodocs] [--noplugins] [--enableplugin [plugin]]
 3                   [--disableplugin [plugin]] [--releasever RELEASEVER] [--setopt SETOPTS]
 4                   [--skip-broken] [-h] [--allowerasing] [-b | --nobest] [-C]
 5                   [-R [minutes]] [-d [debug level]] [--debugsolver] [--showduplicates]
 6                   [-e ERRORLEVEL] [--obsoletes] [--rpmverbosity [debug level name]] [-y]
 7                   [--assumeno] [--enablerepo [repo]] [--disablerepo [repo] | --repo
 8                   [repo]] [--enable | --disable] [-x [package]] [--disableexcludes [repo]]
 9                   [--repofrompath [repo,path]] [--noautoremove] [--nogpgcheck]
10                   [--color COLOR] [--refresh] [-4] [-6] [--destdir DESTDIR]
11                   [--downloadonly] [--comment COMMENT] [--bugfix] [--enhancement]
12                   [--newpackage] [--security] [--advisory ADVISORY] [--bz BUGZILLA]
13                   [--cve CVES] [--sec-severity {Critical,Important,Moderate,Low}]
14                   [--forcearch ARCH] [--duplicates | --oldinstallonly]
15                   [PACKAGE ...]

Here only the options in line 14 (and 15) are specific to this command, all the previous ones are General DNF options.

I propose that this usage message should be simplified by replacing those general option listing with [<general-option> ...]. e.g.

 1  usage: dnf remove [<general-option> ...] [--forcearch ARCH] [--duplicates | --oldinstallonly]
 2                    [PACKAGE ...]

I hope this (along with removing help message for general options on dnf help <command> #1869) will make reading command specific usage meesage and help message much better (tidy) experience.

Hello. Here, the source of installation of dnf appears to be a repository whose ID is anaconda.

$ dnf -q rq --installed --qf '%{epoch}:%{version} %{repoid} %{from_repo}' dnf
0:4.14.0 @System anaconda

However here, that repository's ID is not reported as being available as source of installation of dnf.

$ dnf -q rq --available --showduplicates --qf '%{epoch}:%{version} %{repoid}' dnf
0:4.14.0 fedora
0:4.14.0 updates-testing

Different interpretations may exit to determine a possible issue when served by the question Does a repository's ID named anaconda even exit?

• If it does, the issue involves --available of rq which fails to report that repository's ID.
• If it does not, the issue is that dnf fails to report the repository's ID such as one of those reported by dnf -q rq --available --qf %{repoid} dnf.

DNF v.: 4.16.1 | Hello. It appears that the -q and -v options can be combined without triggering any message related to their combination.

• Case in which the none of those options are used; for reference:

$ dnf repolist fedora
repo id                        repo name                           status
fedora                         Fedora 38 - x86_64                  enabled

• Case in which the -v option is used alone:

$ dnf -v repolist fedora
Loaded plugins: builddep, changelog, config-manager, copr, debug, debuginfo-install, download, generate_completion_cache, groups-manager, needs-restarting, notify-packagekit, playground, repoclosure, repodiff, repograph, repomanage, reposync, system-upgrade
DNF version: 4.16.1
cachedir: /var/tmp/dnf-yk-6v8mefzc
Last metadata expiration check: 0:53:25 ago on Fri Jun  9 12:37:26 2023.
Repo-id            : fedora
Repo-name          : Fedora 38 - x86_64
Repo-status        : enabled
Repo-revision      : 1681418230
Repo-updated       : Thu Apr 13 23:37:10 2023
Repo-pkgs          : 69222
Repo-available-pkgs: 69222
Repo-size          : 98 G
Repo-metalink      : https://mirrors.fedoraproject.org/metalink?repo=fedora-38&arch=x86_64
  Updated          : Fri Jun  9 12:37:21 2023
Repo-baseurl       : rsync://rsync.nic.funet.fi/ftp/pub/mirrors/fedora.redhat.com/pub/fedora/linux/releases/38/Everything/x86_64/os/
                   : (106 more)
Repo-expire        : 604800 second(s) (last: Fri Jun  9 12:37:21 2023)
Repo-filename      : /etc/yum.repos.d/fedora.repo
Total packages: 69222

• Case in which the -q and -v options are combined; that leads to increase the output printed, which is of course contrary to -q's role.

Note: a motivation to use the -q option could be the intention to not print the portion Loaded plugins: (...) DNF version: 4.16.1.

Portion added resulting from that combination:

User-Agent: constructed: 'libdnf (Fedora Linux 38; workstation; Linux.x86_64)'
repo: using cache for: <repository>
fedora: using metadata from <date>.
(...)
repo: using cache for: <repository>
fedora: using metadata from <date>.

I can only test this problem with the following setup, so I don't know if it's still applicable in the trunk version:

• Redhat/Alma/Rocky 8 (with latest updates as of today)
• RPM 4.14.3 (Release 24)
• dnf 4.7.0 (Release 11)

I created a RPM containing "Recommends: dnf-automatic".
When installing this RPM, it doesn't install dnf-automatic. Same with policycoreutils-python-utils.

If I use "Requires: dnf-automatic", it's installed correctly.

Is this a known issue (I don't see anything in github).
Anything I could do to troubleshoot that?
Thanks a lot.

logfilelevel and debuglevel maybe are no useful in /etc/dnf/dnf.conf.

Similar to #1925

When running:

import dnf
base = dnf.Base()
base.read_all_repos()
base.init_plugins()
base.pre_configure_plugins()
base.configure_plugins()
base.fill_sack()

I get this error message:

Errors during downloading metadata for repository 'baseos':
  - Status code: 404 for https://mirrors.rockylinux.org/mirrorlist?arch=x86_64&repo=BaseOS-9$rltype (IP: 199.232.194.132)
Traceback (most recent call last):
  File "/usr/lib/python3.9/site-packages/dnf/repo.py", line 573, in load
    ret = self._repo.load()
  File "/usr/lib64/python3.9/site-packages/libdnf/repo.py", line 331, in load
    return _repo.Repo_load(self)
libdnf._error.Error: Failed to download metadata for repo 'baseos': Cannot prepare internal mirrorlist: Status code: 404 for https://mirrors.rockylinux.org/mirrorlist?arch=x86_64&repo=BaseOS-9$rltype (IP: 199.232.194.132)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.9/site-packages/dnf/base.py", line 401, in fill_sack
    self._add_repo_to_sack(r)
  File "/usr/lib/python3.9/site-packages/dnf/base.py", line 141, in _add_repo_to_sack
    repo.load()
  File "/usr/lib/python3.9/site-packages/dnf/repo.py", line 580, in load
    raise dnf.exceptions.RepoError(str(e))
dnf.exceptions.RepoError: Failed to download metadata for repo 'baseos': Cannot prepare internal mirrorlist: Status code: 404 for https://mirrors.rockylinux.org/mirrorlist?arch=x86_64&repo=BaseOS-9$rltype (IP: 199.232.194.132)

There are two issues with the URL that is shown here:
"$rltype" causes the 404 error
"BaseOS-9" returns incorrect data for the OS version

If you change the URL to: https://mirrors.rockylinux.org/mirrorlist?arch=x86_64&repo=BaseOS-9.0
You get a return of 200 and a list of mirrors.

For some reason when you define the repo as "BaseOS-9" the mirror server has no idea you mean 9.0, it instead offers you 9.1

python3 --version Python 3.9.14

When attempting the solution from #1925, all repos report 404 and all include the "$rltype" at the end of the URL:

Errors during downloading metadata for repository 'baseos':   - Status code: 404 for https://mirrors.rockylinux.org/mirrorlist?arch=x86_64&repo=BaseOS-9$rltype (IP: 199.232.194.132) Error: Failed to download metadata for repo 'baseos': Cannot prepare internal mirrorlist: Status code: 404 for https://mirrors.rockylinux.org/mirrorlist?arch=x86_64&repo=BaseOS-9$rltype (IP: 199.232.194.132) 
Errors during downloading metadata for repository 'appstream':   - Status code: 404 for https://mirrors.rockylinux.org/mirrorlist?arch=x86_64&repo=AppStream-9$rltype (IP: 199.232.194.132) Error: Failed to download metadata for repo 'appstream': Cannot prepare internal mirrorlist: Status code: 404 for https://mirrors.rockylinux.org/mirrorlist?arch=x86_64&repo=AppStream-9$rltype (IP: 199.232.194.132) 
Errors during downloading metadata for repository 'extras':   - Status code: 404 for https://mirrors.rockylinux.org/mirrorlist?arch=x86_64&repo=extras-9$rltype (IP: 199.232.194.132) Error: Failed to download metadata for repo 'extras': Cannot prepare internal mirrorlist: Status code: 404 for https://mirrors.rockylinux.org/mirrorlist?arch=x86_64&repo=extras-9$rltype (IP: 199.232.194.132) 
Ignoring repositories: baseos, appstream, extras

Simply removing the "$rltype" from the end solves the issue

I'd love to override dnf.conf settings without touching the file because future updates may change it.

Can this be done without /etc/dnf/{dnf.d|conf.d}/override.conf or I'm simply missing something?

Dear all,
I have a broken pre-installed dnf such that whenever I write dnf on commandline, I get ModuleNotFoundError: No module named 'libdnf'. That's because I installed python3.8.15 from source with --prefix=/usr. So I tried building dnf from source. Build does not give me any error. But when I execute installed binary from dnf/bin/dnf-2, I get following error:

Traceback (most recent call last):
  File "./dnf-2", line 57, in <module>
    from dnf.cli import main
  File "/root/dnf/dnf/__init__.py", line 31, in <module>
    import dnf.base
  File "/root/dnf/dnf/base.py", line 27, in <module>
    import libdnf.transaction
ImportError: No module named libdnf.transaction

My specifications are as follows:
Architecture: riscv64 (I am using hifive unleashed board from sifive).
Distro: Fedora Rawhide

In a context of a CI/CD build environment, where a new RPM package is published in a repository and is immediately used for installation by dnf, it would be interesting if the command dnf makecache could take an optional repoid to limit making the cache to only this repository.

example : dnf makecache myrepo

Rationale is that on some systems, a lot of slow repositories may be configured, and targeting specifically the right repository to update would speed up significally my CI/CD pipeline run, and limit resource usage.

Upon an operation with failed delta RPMs I'm presented with the message

Failed Delta RPMs increased 148.9 MB of updates to 189.0 MB (21.2% wasted).

Scope of this ticket is the percentage calculation ("21.2% wasted").

The difference between 148.9 MB (full) and 189.0 MB (real) is 40.1 MB. And 40.1 MB is 21.2% of 189.0 MB. But to calculate the size "wasted" (I interpret this to mean needlessly downloaded in addition), shouldn't the percentage calculation be based on the expected full size instead of on the real size?

I'd expect the message to say

Failed Delta RPMs increased 148.9 MB of updates to 189.0 MB (26.9% wasted).

as in 40.1 MB is 26.9% of the original 148.9 MB, and by an increase to 189.0 MB the size was increased by 26.9% of 148.9 MB.

Thanks for a sanity check!

Environment:
dnf 4.14.0, dnf-0:4.14.0-1.fc37.noarch

$ dnf -q rq --installed --qf '%{evr}' dnf
4.14.0-1.fc37

Hello. Due to the lack of descriptions in the manual DNF(8) in respect to the roles of the tags presented as the result of dnf rq --querytags, i reasonably assumed, by analogy with NEVRA whose mention is present in that very manual, that evr has to be the combination of tags epoch, version and release observing the syntax epoch:version-release here after illustrated:

$ dnf -q rq --installed --qf '%{epoch}:%{version}-%{release}' dnf
0:4.14.0-1.fc37

Despite the mention of this evr in command, the value related to_epoch_ is missing.

$ dnf rq --installed --qf '%{evr} | %{from_repo}' libdecor
0.1.1-1.fc37 | updates
$ rpm -ql libdecor | grep libdecor-0.so.0$
/usr/lib64/libdecor-0.so.0
$ dnf rq --installed --whatprovides /usr/lib64/libdecor-0.so.0
libdecor-0:0.1.1-1.fc37.x86_64
$ dnf rq --installed --whatprovides libdecor-0.so.*
libdecor-0:0.1.1-1.fc37.x86_64

v. 4.14.0 | Hello. Then libdecor-0.so.0 is installed and found, be it specified with or without absolute path. However dnf rq --installed --whatprovides libdecor-0.so.0 results in null output. That does not seem to be expected.

This will affect the ability of ‘dnf history rollback‘

dnf:

Setting up Distribution Synchronization Process
Resolving dependencies
--> Starting dependency resolution
--> Finished dependency resolution
Error: problem with installed package empathy-3.9.92-1.fc20.x86_64

yum:

Transaction Summary
========================================================================================================================================================================
Upgrade  19 Packages (+9 Dependent packages)

Total download size: 165 M
Is this ok [y/d/N]: 

In dnf v. 4.14.0

$ sudo dnf alias add upgrade="-y \upgrade"
Aliases added: upgrade
$ dnf alias list
Alias upgrade='-y upgrade'

Hello. As it appears the expression reported by dnf alias list for the existent alias name doesn't match the original expression; " was converted into ', and \ removed.

We have a quite large repo with many historic builds of our software in it. It's large enough that it can take dnf quite a while to parse it's metadata. But usually, it's only the most recent builds in that archive that are used.

It would be interesting to be able to keep, say, the most recent 7 days builds in one (comparatively small) repo and the rest of the historic builds in another and then to be able to tell dnf not to bother with the historic archive repo if what is requested can be found in the recent 7 days repo.

I.e./IOW an optional repo (whose MD is not even fetched and parsed) based on not being able to find something matching an install request in the non-optional repos.

That way somebody installing foo will get the most recent version from the fast repo. Somebody installing a specific version of foo built in the last 7 days also gets it from the fast repo. Somebody wanting to install a build from 3 months ago has to wait for the larger repo.

It might be interesting even to be able to stage these optional repos in an order of priority so that there are multiple levels of speed of installing software depending on how old a version you want. Almost like a hierarchical storage system where if you want something from 10 years ago, you have to wait for it to come from tape, but if you want something from yesterday it comes from fast local disk. This hierarchical part is complete gravy. Even just a single tier as I explain above probably suits 98% of the use-cases.

Such a solution would make most installs take a small few number of minutes (if that even) rather than the (many) 10s of minutes that it can take from the large historic repo.

dnf .v: 4.16.1 | Hello. --repo not operational when its value is a Copr repository.

$ dnf rq --userinstalled --qf '%{from_repo} | %{vendor}' ssh-audit
copr:copr.fedorainfracloud.org:sunwire:ssh-audit | Fedora Copr - user sunwire
$ dnf rq --repo=copr:copr.fedorainfracloud.org:sunwire:ssh-audit --userinstalled --qf %{name}
$ 

Hi,

I recently switched from yum to dnf and I am quite satisfied with the overall quality of dnf. But one thing that eludes me is this: Why would dnf want to emulate the apt separation of update and upgrade?

When asking for an update, one would expect to get the latest no matter when the database cache expires. I can't even find a way to force the update of the cache short of editing dnf.conf, in which case it does update always, even when searching. I see no reason as to why this is desired behaviour short of making cases that I believe have a limited audience.

EDIT: After reading a little more, I found out that check-update did not do what I thought it did.

I have dnf-automatic configured to send e-mail reports. This works very well when dnf-automatic is able to apply updates.

However when it cannot, due to perhaps package conflict or even just needing to accept a new repository key, dnf-automatic is completely silent. No e-mail, no nothing.

So unless I am auditing each morning all of the systems I do get an e-mail about, it's very easy to miss that a system is not being automatically updated, for days or even weeks.

Clearly this is a security issue as one of the primary pros of automatically updating is keeping one's system up-to-date with security updates.

DNF-CONFIG-MANAGER(8) v. 4.3.1 | A section can either be _main_ or a repoid.

In practice

$ dnf config-manager --dump main
Error: No matching repo to modify: main.

Hello. That output message appears to be irrelevant by indicating that dnf is not aware of the existence of main as defined in this manual.

Current description of "dnf module provides" (coded here) is like:

list modular packages

which looks not clear.
How about clarifying the text as something like:

list packages along with modules that provide them

I intend to write a Puppet external custom fact, using DNF's Python API, which would collect all DNF modules data and output as YAML data, ready to be consumed by Puppet Facter.

If any of the DNF repository fails, the DNF Python API fails in the fill_sack step.

My code relevant excerpt:

base = Base()
base.read_all_repos()
base.fill_sack()

This last call fails with:

Traceback (most recent call last):
  File "/tmp/vagrant-puppet/modules-f66d94f6e6659fdb4d59d354e75134fe/dnf_modules/facts.d/dnf_modules.py", line 50, in <module>
    dnf_module_objs = list_module_objs()
  File "/tmp/vagrant-puppet/modules-f66d94f6e6659fdb4d59d354e75134fe/dnf_modules/facts.d/dnf_modules.py", line 27, in list_module_objs
    base.fill_sack()
  File "/usr/lib/python3.9/site-packages/dnf/base.py", line 401, in fill_sack
    self._add_repo_to_sack(r)
  File "/usr/lib/python3.9/site-packages/dnf/base.py", line 141, in _add_repo_to_sack
    repo.load()
  File "/usr/lib/python3.9/site-packages/dnf/repo.py", line 580, in load
    raise dnf.exceptions.RepoError(str(e))
dnf.exceptions.RepoError: Failed to download metadata for repo 'baseos': Cannot prepare internal mirrorlist: Status code: 404 for https://mirrors.rockylinux.org/mirrorlist?arch=x86_64&repo=BaseOS-9$rltype (IP: 151.101.206.132)

I understand the repo issue has to be dealt with. But I'd like my Python code to keep running, with the working repos, to yield useful information, while the repo is fixed elsewhere.

Method Base.fill_sack already uses attribute Base.repos.iter_enabled.skip_if_unavailable or something like that for the purpose I need. But I think this attribute is not available for the Base.fill_sack caller:

    def fill_sack(self, load_system_repo=True, load_available_repos=True):
        ...
                for r in self.repos.iter_enabled():
                    try:
                        self._add_repo_to_sack(r)
                        ...
                    except dnf.exceptions.RepoError as e:
                        ...
                        if r.skip_if_unavailable is False:
                            raise

So my request is a parameter in Base.fill_sack which could set skip_if_unavailable to True

According to the updateinfo command description in code,

 availability.add_argument(
            "--available", dest='_availability', const='available', action='store_const',
            help=_("advisories about newer versions of installed packages (default)"))
        availability.add_argument(
            "--installed", dest='_availability', const='installed', action='store_const',
            help=_("advisories about equal and older versions of installed packages"))

which is from updateinfo.py, the '--available' shows "advisories about newer versions of installed packages (default)", and the '--installed' shows "advisories about equal and older versions of installed packages".
I try to find the upgradable vim-common package with the command of 'dnf updateinfo list cves --available' , but the output shows nothing. And in the output of 'dnf updateinfo list cves --installed', the vim-common packages with higher versions are also echoed.

[root@hostname ~]# rpm -qa | grep vim-common
vim-common-9.0-8.x86_64
[root@hostname ~]# dnf updateinfo list cves --available | grep vim-common
[root@hostname ~]# dnf updateinfo list cves --installed | grep vim-common
CVE-2023-1170  Important/Sec. vim-common-9.0-11.x86_64
CVE-2023-1175  Important/Sec. vim-common-9.0-11.x86_64
CVE-2023-1264  Moderate/Sec.  vim-common-9.0-12.x86_64
CVE-2023-0049  Important/Sec. vim-common-9.0-7.x86_64
CVE-2023-0051  Important/Sec. vim-common-9.0-7.x86_64
CVE-2023-0054  Important/Sec. vim-common-9.0-7.x86_64
CVE-2023-0288  Important/Sec. vim-common-9.0-8.x86_64
CVE-2022-47024 Important/Sec. vim-common-9.0-8.x86_64
CVE-2023-0433  Important/Sec. vim-common-9.0-9.x86_64 

$ dnf rq --installed dnf
dnf-0:4.14.0-1.fc37.noarch

Hello. It seems to me that an installed program

• regardless being running or not, can be determined with dnf rq --installed <package>.
• that is running can be determined with dnf rq --installed --latest-limit 1 <package>.
• that isn't running can be determined with dnf rq --installonly <package>.

The package kernel suits well for a verification of my presumptions as uname -r is aimed tp report an installed kernel that is running. Assumed | System rebooted after the last kernel update was installed.

$ dnf rq --installed kernel
kernel-0:6.1.10-200.fc37.x86_64
kernel-0:6.1.11-200.fc37.x86_64
kernel-0:6.1.9-200.fc37.x86_64
$ dnf rq --installed --latest-limit 1 kernel
kernel-0:6.1.11-200.fc37.x86_64
$ uname -r
6.1.11-200.fc37.x86_64

However with --installonly is reported also the package of a related program that is running –v. 6.1.11. Shouldn't it be not to be reported?

$ dnf rq --installonly kernel
kernel-0:6.1.10-200.fc37.x86_64
kernel-0:6.1.11-200.fc37.x86_64
kernel-0:6.1.9-200.fc37.x86_64

PackageKit wants to read the config file for things like RpmVerbosity, InstallOnlyPkgs and ReposDir. It makes perfect sense to ship this in some shared component. It might be valid to make PK just depend on DNF (even though it's not using DNF directly) and read /etc/dnf.conf, although I'd need to add some more keys in this case. Something like /etc/hawkey.conf might be a good compromise. Ideas welcome.

$ dnf rq --installed dnf
dnf-0:4.14.0-1.fc37.noarch

From manual DNF(8)
<availability> specifies whether advisories about

• newer versions of installed packages (omitted or --available)
• equal and older versions of installed packages (--installed)
• newer versions of those installed packages for which a newer version is available (--updates) or advisories about any versions of installed packages (--all) are taken into account.
(...) --available takes only the latest installed versions of packages into account.

Latest installed version of package kernel

$ dnf rq --installonly --latest-limit=1 kernel
kernel-0:6.1.8-200.fc37.x86_64

Hello. As it appears with --available in command, the version printed is an equal version of installed package not as intended a newer one.

$ dnf upif --list --available bugfix | grep 'kernel\-[[:digit:]].'
FEDORA-2023-b52d72c14e vikakorjaus kernel-6.1.8-200.fc37.x86_64
$ dnf upif --list --installed bugfix | grep 'kernel\-[[:digit:]].'
FEDORA-2023-b52d72c14e vikakorjaus kernel-6.1.8-200.fc37.x86_64

Looks like something is wrong

+ cd dnf-4.14.0
+ /usr/bin/ctest --test-dir noarch-redhat-linux-gnu --output-on-failure --force-new-ctest-process -j48
Internal ctest changing into directory: /home/tkloczko/rpmbuild/BUILD/dnf-4.14.0/noarch-redhat-linux-gnu
Test project /home/tkloczko/rpmbuild/BUILD/dnf-4.14.0/noarch-redhat-linux-gnu
    Start 1: test
1/1 Test #1: test .............................***Failed    8.75 sec
....History database cannot be created, using in-memory database instead: SQLite error on "/tmp/tests/history.sqlite": Open failed: unable to open database file
......History database cannot be created, using in-memory database instead: SQLite error on "/tmp/tests/history.sqlite": Open failed: unable to open database file
...History database cannot be created, using in-memory database instead: SQLite error on "/tmp/tests/history.sqlite": Open failed: unable to open database file
.History database cannot be created, using in-memory database instead: SQLite error on "/tmp/tests/history.sqlite": Open failed: unable to open database file
.History database cannot be created, using in-memory database instead: SQLite error on "/tmp/tests/history.sqlite": Open failed: unable to open database file
...History database cannot be created, using in-memory database instead: SQLite error on "/tmp/tests/history.sqlite": Open failed: unable to open database file
.History database cannot be created, using in-memory database instead: SQLite error on "/tmp/tests/history.sqlite": Open failed: unable to open database file
.History database cannot be created, using in-memory database instead: SQLite error on "/tmp/tests/history.sqlite": Open failed: unable to open database file
......Package tour not installed, cannot downgrade it.
....Package tour not installed, cannot update it.
.......History database cannot be created, using in-memory database instead: SQLite error on "/tmp/tests/history.sqlite": Open failed: unable to open database file
...................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................s..........................................................rpm transaction happens.
rpm transaction happens.
/home/tkloczko/rpmbuild/BUILD/dnf-4.14.0/tests/test_logging.py:52: ResourceWarning: unclosed file <_io.TextIOWrapper name='/tmp/dnf-logtest-9m9nx19x/dnf.rpm.log' mode='a' encoding='UTF-8'>
  for handler in logger.handlers[:]:

./home/tkloczko/rpmbuild/BUILD/dnf-4.14.0/tests/test_logging.py:52: ResourceWarning: unclosed file <_io.TextIOWrapper name='/tmp/dnf-logtest-ntkzecox/dnf.rpm.log' mode='a' encoding='UTF-8'>
  for handler in logger.handlers[:]:

../home/tkloczko/rpmbuild/BUILD/dnf-4.14.0/tests/test_logging.py:52: ResourceWarning: unclosed file <_io.TextIOWrapper name='/tmp/dnf-logtest-slmrp_bx/dnf.rpm.log' mode='a' encoding='UTF-8'>
  for handler in logger.handlers[:]:

/home/tkloczko/rpmbuild/BUILD/dnf-4.14.0/tests/test_logging.py:52: ResourceWarning: unclosed file <_io.TextIOWrapper name='/tmp/dnf-logtest-slmrp_bx/dnf.rpm.log' mode='a' encoding='UTF-8'>
  for handler in logger.handlers[:]:

./home/tkloczko/rpmbuild/BUILD/dnf-4.14.0/tests/test_logging.py:52: ResourceWarning: unclosed file <_io.TextIOWrapper name='/tmp/dnf-logtest-ebamqplc/dnf.rpm.log' mode='a' encoding='UTF-8'>
  for handler in logger.handlers[:]:

/home/tkloczko/rpmbuild/BUILD/dnf-4.14.0/tests/test_logging.py:52: ResourceWarning: unclosed file <_io.TextIOWrapper name='/tmp/dnf-logtest-ebamqplc/dnf.rpm.log' mode='a' encoding='UTF-8'>
  for handler in logger.handlers[:]:

...........Detection of Platform Module failed: No valid Platform ID detected
.Detection of Platform Module failed: No valid Platform ID detected
Unable to resolve argument httpd:invalid
.Detection of Platform Module failed: No valid Platform ID detected
.Detection of Platform Module failed: No valid Platform ID detected
.Detection of Platform Module failed: No valid Platform ID detected
.Detection of Platform Module failed: No valid Platform ID detected
.Detection of Platform Module failed: No valid Platform ID detected
.Detection of Platform Module failed: No valid Platform ID detected
.Detection of Platform Module failed: No valid Platform ID detected
.Detection of Platform Module failed: No valid Platform ID detected
.Detection of Platform Module failed: No valid Platform ID detected
.Detection of Platform Module failed: No valid Platform ID detected
.Detection of Platform Module failed: No valid Platform ID detected
.Detection of Platform Module failed: No valid Platform ID detected
.Detection of Platform Module failed: No valid Platform ID detected
.Detection of Platform Module failed: No valid Platform ID detected
.Detection of Platform Module failed: No valid Platform ID detected
No default profiles for module m4:1.4.18. Available profiles: specific
.Detection of Platform Module failed: No valid Platform ID detected
History database cannot be created, using in-memory database instead: SQLite error on "/home/tkloczko/rpmbuild/BUILD/dnf-4.14.0/tests/modules/var/lib/dnf/history.sqlite": Open failed: unable to open database file
.Detection of Platform Module failed: No valid Platform ID detected
History database cannot be created, using in-memory database instead: SQLite error on "/home/tkloczko/rpmbuild/BUILD/dnf-4.14.0/tests/modules/var/lib/dnf/history.sqlite": Open failed: unable to open database file
.Detection of Platform Module failed: No valid Platform ID detected
.Detection of Platform Module failed: No valid Platform ID detected
History database cannot be created, using in-memory database instead: SQLite error on "/home/tkloczko/rpmbuild/BUILD/dnf-4.14.0/tests/modules/var/lib/dnf/history.sqlite": Open failed: unable to open database file
.Detection of Platform Module failed: No valid Platform ID detected
History database cannot be created, using in-memory database instead: SQLite error on "/home/tkloczko/rpmbuild/BUILD/dnf-4.14.0/tests/modules/var/lib/dnf/history.sqlite": Open failed: unable to open database file
.Detection of Platform Module failed: No valid Platform ID detected
.Detection of Platform Module failed: No valid Platform ID detected
.Detection of Platform Module failed: No valid Platform ID detected
.Detection of Platform Module failed: No valid Platform ID detected
.Detection of Platform Module failed: No valid Platform ID detected
.Detection of Platform Module failed: No valid Platform ID detected
.Detection of Platform Module failed: No valid Platform ID detected
.Detection of Platform Module failed: No valid Platform ID detected
...............FEFFF...................Package hole-1-2.x86_64 not installed, cannot reinstall it.
......................................................................
======================================================================
ERROR: test_config (tests.test_plugin.PluginTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python3.8/site-packages/libdnf/conf.py", line 1804, in ConfigParser__get
    return self.getSubstitutedValue(section, option)
  File "/usr/lib64/python3.8/site-packages/libdnf/conf.py", line 1712, in getSubstitutedValue
    return _conf.ConfigParser_getSubstitutedValue(self, section, key)
IndexError: OptionReader::getValue(): Missing section main

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/tkloczko/rpmbuild/BUILD/dnf-4.14.0/tests/test_plugin.py", line 68, in test_config
    self.assertTrue(conf.getboolean('main', 'enabled'))
  File "/usr/lib64/python3.8/site-packages/libdnf/conf.py", line 1822, in ConfigParser__getboolean
    v = self.get(section, option, raw=raw)
  File "/usr/lib64/python3.8/site-packages/libdnf/conf.py", line 1806, in ConfigParser__get
    raise KeyError(str(e))
KeyError: 'OptionReader::getValue(): Missing section main'

======================================================================
FAIL: test_skip (tests.test_plugin.PluginSkipsTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/tkloczko/rpmbuild/BUILD/dnf-4.14.0/tests/test_plugin.py", line 87, in test_skip
    self.assertLength(self.plugins.plugin_cls, 0)
  File "/home/tkloczko/rpmbuild/BUILD/dnf-4.14.0/tests/support.py", line 598, in assertLength
    return self.assertEqual(len(collection), length)
AssertionError: 20 != 0

======================================================================
FAIL: test_disabled (tests.test_plugin.PluginTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/tkloczko/rpmbuild/BUILD/dnf-4.14.0/tests/test_plugin.py", line 78, in test_disabled
    self.assertLength(self.plugins.plugin_cls, 1)
  File "/home/tkloczko/rpmbuild/BUILD/dnf-4.14.0/tests/support.py", line 598, in assertLength
    return self.assertEqual(len(collection), length)
AssertionError: 21 != 1

======================================================================
FAIL: test_load (tests.test_plugin.PluginTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/tkloczko/rpmbuild/BUILD/dnf-4.14.0/tests/test_plugin.py", line 49, in test_load
    self.assertLength(self.plugins.plugin_cls, 1)
  File "/home/tkloczko/rpmbuild/BUILD/dnf-4.14.0/tests/support.py", line 598, in assertLength
    return self.assertEqual(len(collection), length)
AssertionError: 21 != 1

======================================================================
FAIL: test_runs (tests.test_plugin.PluginTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/tkloczko/rpmbuild/BUILD/dnf-4.14.0/tests/test_plugin.py", line 57, in test_runs
    self.assertLength(self.plugins.plugins, 1)
  File "/home/tkloczko/rpmbuild/BUILD/dnf-4.14.0/tests/support.py", line 598, in assertLength
    return self.assertEqual(len(collection), length)
AssertionError: 21 != 1

----------------------------------------------------------------------
Ran 796 tests in 8.148s

FAILED (failures=4, errors=1, skipped=1)


0% tests passed, 1 tests failed out of 1

Total Test time (real) =   8.75 sec

The following tests FAILED:
          1 - test (Failed)
Errors while running CTest

Description

Hello. The need for a such option for DNF v. 4/5 can be proved if needed, as the related task cannot be accomplished by anyone other than someone who knows that

• external tools are needed to accomplish this task
• knowledge of such external tools is required

In that context, it is likely that the accomplishment of that task becomes most improbable for most of us, as illustrated by the command needed to produce in order to accomplish it:

dnf rq --installed --qf '%{from_repo} | %{name}' | sort -k 1,1 | awk '$1=="repository_1";$1=="repository_2" {print $0}'

Application with values; output truncated:

$ dnf rq --installed --qf '%{from_repo} | %{name}' | sort -k 1,1 | awk '$1=="updates";$1=="updates-testing" {print $0}' 
updates | aajohan-comfortaa-fonts
updates | aardvark-dns
(...)
updates-testing | zchunk-libs
updates-testing | zfs-fuse

Suggestion of model

--installed-from-repo=<repository_1>,<repository_2>,(...)

Wildcard support would be beneficial. Testing against the following command indicates no warning message related to the use of wildcard for --repo, thus implies it to be supported. However an empty output suggests either it is not or an issue:

$ dnf -q rq --available --repo=updates* --qf '%{repoid} | %{version}' dnf
$ 

In my linux machine, I have release-1 installed which contains a rpm foo-1.0.
foo-1.0 has obsoletes dependency with bar.

# rpm -q  --obsoletes base/foo-1.0-0.x86_64.rpm
bar

Now I'm trying to update to release-2.
In release-2, foo-2.0 has removed obsoletes dependency with bar.

# rpm -q  --obsoletes update/foo-2.0-0.x86_64.rpm
# 

release-2 also adds new rpm bar-2.0.

The release wise updates are handled via ansible dnf module which sets update_only: false i.e it installs new packages as well as updates packages in same transaction.
For demonstration, I am using dnf command directly.

Update to release-2 rpms is failing:

# dnf --verbose install --best foo bar
Loaded plugins: builddep, config-manager, copr, debug, debuginfo-install, download, generate_completion_cache, leaves, needs-restarting, playground, repoclosure, repodiff, repograph, repomanage, reposync, show-leaves, versionlock
DNF version: 4.0.9
cachedir: /var/cache/dnf
repo: using cache for: My_Base
not found other for: repo location
not found modules for: repo location
not found deltainfo for: repo location
not found updateinfo for: repo location
My_Base: using metadata from Tue 04 Apr 2023 03:38:38 PM IST.
repo: using cache for: My_Update
not found other for: repo location
not found modules for: repo location
not found deltainfo for: repo location
not found updateinfo for: repo location
My_Update: using metadata from Tue 04 Apr 2023 03:39:34 PM IST.
Last metadata expiration check: 0:12:35 ago on Tue 04 Apr 2023 03:39:44 PM IST.
No module defaults found
Completion plugin: Generating completion cache...
Package foo-1.0-0.x86_64 is already installed.
Package foo-1.0-0.x86_64 is already installed.
--> Starting dependency resolution
--> Finished dependency resolution
Error:
 Problem: cannot install both foo-2.0-0.x86_64 and foo-1.0-0.x86_64
  - cannot install the best candidate for the job
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages)

I was expecting update to work, as later version of foo which removes the obsoletes dependency is also part of same transaction.
How can this be handled? I want foo-2.0 and bar-2.0 to be updated in a single dnf transaction.

# rpm --version
RPM version 4.14.2.1

# dnf --version
4.0.9

libdnf.module.ModulePackage objects have the module, stream and profile names, thru methods getName, getStream and getProfiles, plus the stream default profile (if there is), via getDefaultProfile.

Are there methods and/or attributes, or maybe other classes, which inform if a stream is enabled and/or default, and which is the enabled profile?

I could work it around by a system call to the shell with dnf module commands and a quite convoluted awk filter. But, obviously, this gets cumbersome and results in an additional (and probably avoidable) system call.

It used to be possible to run reposync as a non-privileged user but that no longer appears to be the case. It fails with

Failed to load expired repos cache: [Errno 13] Permission denied: '/var/cache/yum'
[Errno 13] Permission denied: '/var/cache/yum'

This is on EL9.2 - used to work fine on EL7.9

I'm attempting to write a depedency manager for another application that interfaces with DNF. In this application, I need to know the total install size of a list of packages to be able to report progress properly (in increments) and thus performs something like this;

total_size = 0
for pkg in pkgs:
  total_size += pkg.installsize

However, when a transaction begins in the install progress (dnf.callback.TransactionProgress) the sum of all ti_ total, i.e. the value of all ti_total for each package summed up, do not match the above statement.

Is there a way to find out actual installsize of packages, i.e. what get reported as ti_total to the progress method of dnf.callback.TransactionProgress?

I suppose one better way to ask this question, is there a way to query transaction size (ti_total) of a package, represented during the action of dnf.transaction.PKG_INSTALL - before actually beginning the transaction progress?

Also off topic and a non-issue, but I figured I'd ask it since I don't know where else to turn; is there a way to cancel a transaction in progress? I was trying to raise an exception inside dnf.callback.TransactionProgress.progress(...) but that doesn't stop it, it just continues.

@m-blaha @AdamWill @j-mracek @pkratoch currently choosing http or https mirror is done automatically by dnf , i have to block http protocol completely to force dnf upgrade/download software through https mirrors.

i understand that packages installed by dnf will be checked with digital signatures to detect tampering but i would like to prevent network adversaries from easily knowing which packages and which version of package i am using. is there any easy way to achieve this. ( I understand that using https alone wont stop network analysis like by comparing size of downloads with size of known packages but my aim is make network analysis harder , in apt using https mirrors of debian in sourcelist allows me to achieve such a functionality)

Hi,

I have these messages on almalinux 9/ Rocky Linux 9

[mickael@srvalmalinux ~]$ sudo /usr/bin/dnf-automatic /etc/dnf/automatic.conf --timer
Last metadata expiration check: 2:45:52 ago on Fri Mar 10 14:38:38 2023.
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Traceback (most recent call last):
File "/usr/bin/dnf-automatic", line 36, in
sys.exit(dnf.automatic.main.main(sys.argv[1:]))
File "/usr/lib/python3.9/site-packages/dnf/automatic/main.py", line 342, in main
emitters.commit()
File "/usr/lib/python3.9/site-packages/dnf/util.py", line 526, in fn
return list(map(call_what, self))
File "/usr/lib/python3.9/site-packages/dnf/util.py", line 525, in call_what
return method(*args, **kwargs)
File "/usr/lib/python3.9/site-packages/dnf/automatic/emitter.py", line 106, in commit
smtp = smtplib.SMTP(self._conf.email_host, timeout=300)
File "/usr/lib64/python3.9/smtplib.py", line 255, in init
(code, msg) = self.connect(host, port)
File "/usr/lib64/python3.9/smtplib.py", line 341, in connect
self.sock = self._get_socket(host, port, self.timeout)
File "/usr/lib64/python3.9/smtplib.py", line 312, in _get_socket
return socket.create_connection((host, port), timeout,
File "/usr/lib64/python3.9/socket.py", line 844, in create_connection
raise err
File "/usr/lib64/python3.9/socket.py", line 832, in create_connection
sock.connect(sa)
ConnectionRefusedError: [Errno 111] Connection refused

Hi,

I'm trying to get dnf-automatic working with command_email. The latest problem is funny quoting on the subject of the email. The command_format I'm using is the default:

command_format = "mail -Ssendwait -s {subject} -r {email_from} {email_to}"

And this results in email sending to fail. If I check the results from journal, this is the error (newlines and indents added for clarity):

Jan 31 07:02:10 beartrap dnf-automatic[666342]: Failed to execute command 'mail -Ssendwait 
    -s 'Updates applied on '"'"'beartrap'"'"'.' 
    -r [email protected] [email protected]': returned 1

As you can see, the subject containing the hostname is loaded with various quotes.

The systems is a Fedora-37, and def-automatic is 4.14.0

The updateinfo --verbose helpfully outputs the dates of the advisories. That is something I need to use to track if I've installed updates with my window.

Unfortunately, that also provides a bunch of debugging information for dnf. I'd also rather not try and build tooling that figures out which repos pulled down new metadata and printed that operation to stdout.

I'm really just looking for the output from https://github.com/rpm-software-management/dnf/blob/master/dnf/cli/commands/updateinfo.py#L348 and nothing else.

It seems I can have --quiet mode and no dates, or --verbose mode and a ton of extra data along with my dates.

I'll confess, some sort of json output mode would make my day.

It would be good to have --test option with commands like install, upgrade, buildep. That option should do all checks without installing/upgrade actual packages.

I have several thin clients that that are often unused but also want them to be regularly updated. I want them to be shutdown afterwards as they are automatically started regularly via hardware wake up. While I did set the reboot_command to a loginctl script to check if a certain user is logged into a session so computer doesn't shutdown on the user, I had issues cleanly getting this to activate with systemd. Rather than maintain the systemd hack for each of the devices to make this work it would be convenient if always shutting down was built in to dnf-automatic. I propose a new option reboot:
always - Will always execute the reboot_command.

v. 4.14.0 | Hello. Fake packages not detected.

$ dnf --installed list gpg-pubkey*
Error: No matching Packages to list

Despite their presence is attested:

$ rpm -qa gpg-pubkey | wc -l
2

PackageKit needs to know where a package was installed from. Yum uses the yumdb which is frankly horrific. Zif used a sqlite database which in my biased view was much more maintainable, and also threadsafe. The PackageKit backend is using librepo and hawkey and it makes sense to share the origin data between dnf and PackageKit. Ideas welcome.

If I try to provide a --dnf-cmd command some switches they either get taken as part of the command name or mock options.

$ mock -r alma+epel-9-x86_64 --dnf-cmd repoquery\ -a
...
Finish: chroot init
No matches found for the following disable plugin patterns: local, spacewalk, versionlock
No such command: repoquery -a. Please use /usr/bin/dnf --help
It could be a DNF plugin command, try: "dnf install 'dnf-command(repoquery -a)'"
ERROR: Command failed: 
 # /usr/bin/systemd-nspawn -q -M 35789f25f0ec44b5be55926fab6fd156 -D /var/lib/mock/alma+epel-9-x86_64-bootstrap/root -a --capability=cap_ipc_lock --bind=/tmp/mock-resolv.jr6qqq0_:/etc/resolv.conf --console=pipe --setenv=TERM=vt100 --setenv=SHELL=/bin/bash --setenv=HOME=/var/lib/mock/alma+epel-9-x86_64/root/installation-homedir --setenv=HOSTNAME=mock --setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin --setenv=PROMPT_COMMAND=printf "\033]0;<mock-chroot>\007" --setenv=PS1=<mock-chroot> \s-\v\$  --setenv=LANG=C.UTF-8 --setenv=LC_MESSAGES=C.UTF-8 --resolv-conf=off /usr/bin/dnf --installroot /var/lib/mock/alma+epel-9-x86_64/root/ --releasever 9 --setopt=deltarpm=False --allowerasing --disableplugin=local --disableplugin=spacewalk --disableplugin=versionlock repoquery -a --setopt=tsflags=nocontexts
$ mock -r alma+epel-9-x86_64 --dnf-cmd repoquery -a
usage: 
       mock [options] {--init|--clean|--scrub=[all,chroot,cache,root-cache,c-cache,yum-cache,dnf-cache,lvm,overlayfs]}
       mock [options] [--rebuild] /path/to/srpm(s)
       mock [options] [--chain] /path/to/srpm(s)
       mock [options] --buildsrpm {--spec /path/to/spec --sources /path/to/src|
       --scm-enable [--scm-option key=value]}
       mock [options] {--shell|--chroot} <cmd>
       mock [options] --installdeps {SRPM|RPM}
       mock [options] --install PACKAGE
       mock [options] --copyin path [..path] destination
       mock [options] --copyout path [..path] destination
       mock [options] --scm-enable [--scm-option key=value]
       mock [options] --dnf-cmd arguments
       mock [options] --yum-cmd arguments
mock: error: argument -a/--addrepo: expected one argument

So quoted and not, neither work.

When updating the system if there is a new version of dnf. First update itself in dnf( dnf update dnf ).
and then all other packages. Or suggest updating dnf action y/n first and only then update all packages.