There is one negative part of the request - if the same package will be available from multiple repositories - dnf will report separate error report for each package. Currently DNF de-duplitate identical reports.

I would like to ask you for a feedback for the format of output. What do you think about:

                "package bloop-ext-2.0-1.noarch@updates requires bloop = 2.0-1, but none of the providers can be installed",
                "cannot install both bloop-2.0-1.noarch@updates and bloop-1.0-1.noarch@@System",
                "conflicting requests",
                "package bloop-ext-1.0-1.noarch@updates is filtered out by exclude filtering"

or

                "package bloop-ext-2.0-1.noarch from 'updates' requires bloop = 2.0-1, but none of the providers can be installed",
                "cannot install both bloop-2.0-1.noarch from `updates` and bloop-1.0-1.noarch from `@System`",
                "conflicting requests",
                "package bloop-ext-1.0-1.noarch from `updates` is filtered out by exclude filtering"

Or do you have any other idea?

IMHO, the second suggested formatting is more clear and self descriptive (from 'updates'...). The '@' sign is already used for group ids which might be confusing.

 from `updates` looks fine to me as it's more readable, also we can also consider having format bloop-2.0-1.noarch(updates) like we had something with yum previously.

Just another opinion, but +1 for the "from '<repoid>'" format. It looks like the most straightforward.

Thank you very much for feedback.

I checked implementation in libdnf and it looks like that using "from '<repoid>'" will require additional changes in modules data structure, because formatting errors is shared with modules.

I have a patch that enhance error messages: https://github.com/rpm-software-management/libdnf/pull/1596

VERIFIED with run-upstream-tests-on-rhel/see list below

NEW: libdnf-0.69.0-5.el9

19 features passed, 0 failed, 0 skipped
214 scenarios passed, 0 failed, 12 skipped
1507 steps passed, 0 failed, 87 skipped, 0 undefined
Took 1m4.987s

OLD: libdnf-0.69.0-3.el9_2.x86_64

Failing scenarios:
  dnf/broken-dependencies-report.feature:13  Broken dependencies are reported when strict and best options are off
  dnf/broken-dependencies-report.feature:37  Broken dependencies are reported when strict option is off and best option is on
  dnf/broken-dependencies-report.feature:61  Broken dependencies are reported when skip-broken and best options are on
  dnf/comps-group.feature:95  Install and remove group with excluded package dependency
  dnf/history-undo-dependant.feature:4  Undo module install with dependent userinstalled package
  dnf/install-dependencies.feature:8  Best candidates have conflicting dependencies
  dnf/install-exclude.feature:14  Install an RPM that requires excluded RPM
  dnf/microdnf/upgrade.feature:102  Upgrade all RPMs from multiple repositories with best=True
  dnf/module/enable-contexts.feature:48  An error is printed with no stream and context is possible to enable
  dnf/module/enable-dependencies.feature:241  Module cannot be disabled if there are other enabled streams requiring it
  dnf/module/enable-dependencies.feature:302  Cannot enable a stream depending on a disabled module
  dnf/module/enable-errors.feature:163  Enabling a stream depending on other than enabled stream should fail
  dnf/module/enable-errors.feature:198  Enabling a stream depending on a disabled stream should fail
  dnf/module/enable-errors.feature:236  Enabling two modules both requiring different streams of another module
  dnf/module/enable-errors.feature:248  Enabling module stream and another module requiring another stream
  dnf/module/install-module-static-context.feature:95  Install and upgrade from context with broken dependencies => static_context=true
  dnf/module/install.feature:68  Installing a module and its dependencies, non-modular dependency is not available
  dnf/obsoletes.feature:259  Both packages are installed when group contains both obsoleter and obsoleted packages and obsoletes are switched off
  dnf/plugins-core/builddep-modularity.feature:47  Builddep reports error where required package is available only in non-enabled non-default stream
  dnf/plugins-core/download-binary.feature:46  Error when failed to resolve dependencies
  dnf/repoquery/main.feature:585  repoquery --unsatisfied
  dnf/security-upgrade.feature:25  --security upgrade with advisories with pkgs of different arches (noarch variant)
  dnf/stick-to-vendor.feature:47  Downgrade is unable to resolve transaction
  dnf/transaction-sr/replay-errors.feature:250  Replay a transaction with a dependency conflict
  dnf/transaction-sr/replay-errors.feature:295  Replay a transaction with a broken dependency
  dnf/upgrade.feature:58  Upgrade all RPMs from multiple repositories with best=False
  dnf/upgrade.feature:88  Upgrade all RPMs from multiple repositories with best=True

0 features passed, 19 failed, 0 skipped
187 scenarios passed, 27 failed, 12 skipped
1455 steps passed, 27 failed, 112 skipped, 0 undefined
Took 1m1.382s

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 (libdnf bug fix and enhancement update), 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-2023:6647