Rocky Linux retry safety limits: atomic DNF payloads versus repeated RPM scriptlet writes

Rocky Linux uses DNF to manage packages, and its download layer retries transient network failures according to configured retry, timeout, and minrate values. Completed payloads are written to temporary files and renamed into place, which prevents duplicated or truncated package files on a re-attempted download. The unresolved boundary sits at the RPM transaction layer: %pre and %post scriptlet side effects—such as creating users, appending configuration lines, or seeding caches—are not automatically idempotent and are not rolled back if a transaction is interrupted and then re-run. Although dnf history rollback can revert package payloads and rpmdb changes, it does not undo external scriptlet writes, so duplicated side effects can persist. Because default retry settings and the DNF generation differ across Rocky minor releases, the exact behavior must be verified against the installed version.

Which retry and timeout defaults apply to the installed Rocky minor release, and do they vary by DNF generation? Is there a documented packaging requirement or DNF/RPM mechanism that guarantees %post scriptlet writes are safe to repeat after an interrupted transaction? Does dnf history rollback on Rocky Linux ever include external side effects from scriptlets, or are those always outside its scope?