:thumbsup:

IIUC this came up in the context of https://pagure.io/fesco/issue/3526

I moreover agree, just two nits:

2) Recent versions of RPM / dnf5 don't even relay scriptlet stdout / stderr to terminal output, things only get written to dnf5 log files in some cases.

Even in logs, they have its meaning if something ges wrong and you dig for why

3) Messages printed by scriptlets are invisible for almost all users anyway since they're not shown when using the recommended upgrade methods

"almost all" may not see them, but they still may be valuable to the remaining few.

+1

+1. Scriplets output is never shown to users on atomic variants so any action that should happen on updates should be handled differently.

+1 it's also possible for that to break due to lack of devfs or tty or whatever, and that can cause the transaction to fail horribly.

Recent versions of RPM / dnf5 don't even relay scriptlet stdout / stderr to terminal output, things only get written to dnf5 log files in some cases.

I would argue that this is bad design. Any system which is a black box is hard to use. I think that what happens with dnf logs is less of anything done purposefully and to follow some design, but more of an accident of implementation. I want rpm+dnf to show things printed by scriptlets on the console so that things can be meaningfully debugged and understood.

Packages MUST NOT rely on writing to stdout / stderr in RPM scriptlets
for the purpose of communicating non-fatal issues, warnings, or other messages
to the user.

This is ambiguous. "Must not rely on writing" could mean "must not write" or "may write but the output may get suppressed". Does "non-fatal issues, warnings, or other messages" mean that "fatal messages" can be written and the package can rely on this? I expect that package scriptlets must not fail, so fatal messages shouldn't happen…

To summarize, I think that:
1. It's OK for scriptlets to judiciously output interesting information to stdout or stderr.
2. dnf should carefully handle stdout and stderr. It certainly should log those, but maybe it should also present them on the console when dnf is run directly.
3. Packages must not assume that a human is reading those.
4. It would be absolutely wonderful if dnf could be taught to be less verbose through some settings. E.g. in CI runs, having 10k lines of info about packages being downloaded is completely useless. If we could compress this triplicated info (list of packages to install, download of each package, list of packages installed) to one repeat, we'd save a number of trees in Amazonia and developer hours.

1. Packages must not assume that a human is reading those.

This I agree with, and is the reason why I filed this issue.

If you cannot assume that a human is reading the messages, then you should not rely on this mechanism to print "non-fatal issues, warnings, or other messages".

This is ambiguous.

Apparently the wording is not ambiguous. Because you understood 100% correctly what I intended to say with this. :)

Printing output from fatal issues that happen in scriptlets is OK because that's the only thing you can do - since making the scriptlet fail the transaction is a big no-no.

Unfortunately many of the output handling changes are intentional (see gh#rpm-software-management/dnf5#326 and gh#rpm-software-management/dnf5#2116 as examples of how even standard DNF output handling has changed in less than ideal ways). I do not expect changes to make output more accessible to be in the cards.