Differences between fedrq and dnf repoquery

While fedrq and dnf repoquery have similar functionality, their respective interfaces possess some key differences. The author believes these differences make fedrq more powerful and user friendly, but experienced dnf repoquery users should keep them in mind.

Default repositories

By default, dnf repoquery reads the system configuration and queries the repositories with enabled=1 in their configurations — and nothing more. fedrq, on the other hand, behaves more like fedpkg. Queries default to rawhide and enable the rawhide and rawhide-source repositories. This can be changed using the -b / --branch flags on the CLI or permanently changed with the default_branch option in the configuration. See the BUILTIN RELEASES section of man fedrq for valid --branch options. Users can of course configure their own custom release profiles.

To emulate dnf’s default behavior, pass --branch local which includes the default repositories with enabled=1 in /etc/yum.repos.d and the system’s releasever.

Source repositories

fedrq enables source repositories by default in its builtin release configs. While users are free to include whichever repositories they wish in their local configurations, commands such as fedrq subpkgs and fedrq whatrequires-src will not work properly without source repositories enabled.

Release configurations

Release configurations contain three main parts:

• version — this is a regex of matching branches. For example, the repository definition for the Fedora branches configuration is ^f(\d{2})$. Therefore, --branch f37 and --branch f36 will match this configuration and the $releasever will be set to 37 and 36, respectively.
• defs — this is a mapping of profile names to a list of repository IDs. Each release has a base profile which is the default profile for that release. Others can be selected with -r / --repo.

fedrq can read configuration from .repo files located outside of /etc/yum.repos.d/ if they’re specified in the release’s defpaths.

The configuration syntax is described more in man 5 fedrq.

--latest

fedrq applies --latest=1 by default. This means that only one package version will be shown for each architecture. dnf repoquery, on the other hand, shows everything. You can pass --latest=all to fedrq to change this behavior.

--repo and --enablerepo

fedrq also supports --repo and --enablerepo, but they have additional functionality. In addition repoids, these options accept release-specific group names (these are configured in a release’s defs as explained above), and generic repo classes.

For example, you can pass -b f37 -r @copr:gotmax23/fedrq to query only the gotmax23/fedrq fedora-37 Copr chroot’s repositories. You can pass -b f37 --enablerepo @copr:gotmax23/fedrq if you want to enable that Copr’s repository on top of the base repositories.

See the REPO CLASSES section of man fedrq for more information.

Subcommands

fedrq’s CLI interface is split into subcommands unlike dnf repoquery which relies on flags.

See man fedrq for an in depth orientation of fedrq’s CLI interface.

--requires, --provides, and other package attributes

dnf repoquery has flags such as --requires and --provides to determine certain package attributes. fedrq supports these operations via the pkgs subcommand and the -F / --formatter flag. See the table below for some examples.

dnf repoquery --requires PACKAGE	fedrq pkgs -F requires PACKAGE
dnf repoquery --provides PACKAGE	fedrq pkgs -F provides PACKAGE
dnf repoquery --qf "%{name}\n" PACKAGE	fedrq pkgs -F name PACKAGE

See the FORMATTERS section of man fedrq for more information about available formatters.