Today we've been talking to a package maintainer of [FEDORA-2025-0cfda7c73a](https://bodhi.fedoraproject.org/updates/FEDORA-2025-0cfda7c73a) update, which failed [OpenQA gating](https://openqa.fedoraproject.org/tests/overview?distri=fedora&version=43&build=Update-FEDORA-2025-0cfda7c73a&groupid=2&t=2025-09-24+12%3A22%3A27+%2B0000).

There was a frustration about not understanding what the problem is, until we (QA) could provide him with a simple package dependency [error message](https://bodhi.fedoraproject.org/updates/FEDORA-2025-0cfda7c73a#comment-4349500). It would be much easier if at least for these very trivial cases (the update can't be installed!), we could do a better job and let packagers figure out the problem themselves (without forcing them to become OpenQA masters).

Quite interestingly, I wasn't able to easily figure out what the problem was. Only when I pinged Lukas, he could. That shows that this is far from easy.

I see the following issues:
1. There are lots (tens) of failed tests. In some tests, finding the error message is relatively easier, but in some, it's much harder.
2. Even in those "easier to find error" tests, you still need to know where to look (e.g. several screenshots/pages back).

In the Bodhi automated tests tab, there are tens of tests to click on. If you get lucky, you pick e.g. [desktop_background test](https://openqa.fedoraproject.org/tests/3793780#), where the error is presented two screens before the red-colored screen. But if you get unlucky and pick e.g. [install_default_update_live test](https://openqa.fedoraproject.org/tests/3793904#), then I still have no idea how to figure out the error from that page.

Can we do better (without significant engineering efforts)?
Here is my completely naive idea:

1. Create a single pre-requisite test which will try to install an update. It if succeeds, run all the other tests as child tests. If it fails, don't run the child tests. In this case, Bodhi update would show only a single failed test, and the rest would be missing, instead of failed. That would incentivize the packager to click on the single red one.
2. We can fine-tune this single "install update" test to be user-friendly visually. If we detect that the update can't be installed, we can make sure that this is the screen that we fail on. Meaning the clicking the obvious red rectangle would show the error to the user immediately. (If we can't do it because technical reasons, it could still be the last one before the red one?).
3. We could also save the dnf error output in this case into a specialized log file and upload it as an asset. So if things get more complex in some cases, and the error dialog is not in the very last, or the last but one screen, people (including me!) can still find it easily in Assets. (Yes, this is non-straightforward, and relies on knowledge. But as a fallback, it's better to have something that at least someone knowledgeable can find, than not having it at all).

Please tell me how great idea this is, or that it's a technically impossible solution but you have a better idea