Running `dnf update` on a RHEL-8 guest (installed from the 
'nightly-1590', built on 07SEP2018) results in the transaction itself
succeeding, but throws: "Errors occurred during transaction" on the
shell.

From the /var/log/dnf.log (full log in the attachment):

    [...]
    2018-12-06T09:39:58Z SUBDEBUG
    Traceback (most recent call last):
      File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 64, in main
        return _main(base, args, cli_class, option_parser_class)
      File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 99, in _main
        return cli_run(cli, base)
      File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 123, in cli_run
        ret = resolving(cli, base)
      File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 154, in resolving
        base.do_transaction(display=displays)
      File "/usr/lib/python3.6/site-packages/dnf/cli/cli.py", line 249, in do_transaction
        for tsi in trans:
    dnf.exceptions.Error: Transaction failed
    2018-12-06T09:39:58Z CRITICAL Error: Transaction failed
    [...]

And from the /var/log/dnf.rpm.log (full log in the attachment):

    [...]
    2018-12-06T09:37:05Z ERROR Error in POSTUN scriptlet in rpm package bind-export-libs
    2018-12-06T09:37:05Z ERROR Error in POSTUN scriptlet in rpm package bind-export-libs
    [...]

When I say "transaction itself succeeded, I mean the subsequent runs of 
`dnf clean all` && `dnf update` do _not_ result in any failures.

So there doesn't seem to be any real underlying error.  But talking to
Jaroslav Mracek on IRC, he says that the exception is being raised in 
the incorrect place, and suggested to file this bug.