>> 1) replacing %_unsafe_rollbacks with a precise check on rollback >> transaction elements.
>on a per-package basis ? IIUC, currently rpm won't rollback any >transaction whose tid is below the value of %_unsafe_rollbacks. How is >this going to change ?
No, not per-package, per-transaction.
Rollbacks depend on time reversal symmetry. Any upgrade transaction can be downgraded by switch installed <-> erased elements.
The issue is that repackaged packages are stored on the file system, and that information might be incomplete.
Since installed packages now have backward links (and erased packages have forward links) to the other components in the transaction, the check will be to insure that all the necessary elements are part of a rollback transaction.
That prevents a rollback transaction from merrily erasing all installed packages if/when /var/spool/repackage contents are unavailable, and insures that any upgrades are downgraded accurately.
The macro %_unsafe_rollback to set an earliest rollback epoch is a much cruder mechanism, and is more difficult to administer because of the nerdy timestamp represented as a decimal number.
And the "unsafe" in the macro name is not exactly gud marketing 
hth
73 de Jeff
|