I checked dnf code for usage of unbound. It used in dnssec.py for gpgkey_dns_verification. The feature is optional and enabled by configuration option gpgkey_dns_verification. DNF requires python3-unbound only when gpgkey_dns_verification is True.

```
    @staticmethod
    def _cache_miss(input_key):
        # type: (KeyInfo) -> Validity
        """
        In case the key was not found in the cache, create an Unbound context and contact the DNS
        system
        """
        try:
            import unbound
        except ImportError as e:
            msg = _("Configuration option 'gpgkey_dns_verification' requires "
                    "python3-unbound ({})".format(e))
            raise dnf.exceptions.Error(msg)
```

I am not sure what would be the best approach to resolve it. Any suggestion?

It's true that Red Hat publishes the GPG keys used for signing rpms in DNS

$ cat /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
$ dig 5d2d3ceb7abe552344276d47d36a8175b7aeb250a9bf0bf00e850cd2._openpgpkey.redhat.com OPENPGPKEY

so the option gpgkey_dns_verification could be used to verify import of those keys. However, the gpgkey_dns_verification functionality depends on DNSSEC and redhat.com does not use DNSSEC:

$ dig +dnssec 5d2d3ceb7abe552344276d47d36a8175b7aeb250a9bf0bf00e850cd2._openpgpkey.redhat.com OPENPGPKEY | grep RRSIG

(yes, the ad flag should also be checked -- it's not there either :-)

I assume that is why that option is not enabled by default in default RHEL installation because it would not work for any of Red Hat's official rpms.

Granted, the customer could use that option for their own repositories and packages ... but if they configure that, they can just as well add python3-unbound to their kickstarts or rpm --import their keys in their kickstarts to make the setup work.

For that reason I would not consider the dependency on python3-unbound to be critical at this point.

The dependency on deltarpm is already removed in RHEL 9.

We can remove the dependency on python3-unbound based on comment 3, comment 4 and comment 5.

As for the rpm-plugin-systemd-inhibit, I believe this is actually a valid use case of the "Recommends". It is not strictly required, since dnf can work without it, but we want to have it installed by default, because it's important for preventing transaction interruption (see bug 1109927). How about turning the dependency into "Recommends: (rpm-plugin-systemd-inhibit if systemd)"? Then at least the dependency wouldn't get pulled in on systems without systemd.

The "Recommends: (rpm-plugin-systemd-inhibit if systemd)" seems sound ... but why wouldn't we want to do "Requires: (rpm-plugin-systemd-inhibit if systemd)"?

(In reply to Jan Pazdziora from comment #9)
> The "Recommends: (rpm-plugin-systemd-inhibit if systemd)" seems sound ...
> but why wouldn't we want to do "Requires: (rpm-plugin-systemd-inhibit if
> systemd)"?

Because it would be an unnecessary restriction, since dnf can function without the plugin.

PR: https://github.com/rpm-software-management/dnf/pull/1798

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (new packages: dnf), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:3957