Allow non-pre scriptlets to fail the install (again)

[lnussel]

I am trying to use file triggers to perform actions when a kernel gets installed. Ie copy the kernel into the ESP and create boot entries. It could happen that the ESP runs out of space. In that case the system would not boot. In a traditional system one would be doomed anyway. In a transactional system however the system to boot next gets prepared as snapshot in a chroot. So that snapshot can just be thrown away when it can't be made bootable (in fact if anything goes wrong, such as rpm scriptlets).
Unfortunately AFAICT the return value of file triggers is ignored, see

rpm/lib/transaction.c

Line 1876 in 33bc736

runFileTriggers(ts, NULL, RPMSENSE_TRIGGERIN, RPMSCRIPT_TRANSFILETRIGGER, 0);

So we never know whether the transaction had any failures in file triggers. In fact according to the code no post transaction scriptlets and neither plugins can make rpmtsRun() fail. Is there a reason for that resp any chance to change that?

[pmatilai]

This is one of those semi-annual issues ever since, somewhat controversially, changed in rpm 4.6.0.

See https://bugzilla.redhat.com/show_bug.cgi?id=216221 and https://bugzilla.redhat.com/show_bug.cgi?id=465409 for some background. In retrospective, just ignoring all non-pre scriptlet errors may well have been a mistake, I was still very green at the time.

Changing back to the old behavior would not make the related problems go away though, it would just change the ones you encounter. Duplicate headers left behind in the db and needing cleanup are one, but there's also the error code semantics to consider: rpm cannot undo installations, so once the files have been laid down there's no way of going back. So the current rpmtsRun() error code (which bubbles up all the way up to the cli exit code) basically tells you whether the files were successfully laid down, because that's a clear line rpm can draw. An API user can detect all scriptlet failures via the callback, but returning a failure when rpm returns success for the same gets confusing, and so is best avoided.