I see in my overnight email spool: https://bugzilla.redhat.com/show_bug.cgi?id=726872
I am amused because this kind of request comes up time and time again with respect the package management system
It is technically _possible_ to attain this kind of rollbacks, in some tightly controlled environments [something like cell phone tower control computer applications, where there are essentially NO end users in the environment and the computer is acting like an embedded controller], but in the general case with many diverse and randomly maintained packages, each with their own assumptions as to how to maintain their run-time environments, it is 'not gonna happen'' (TM)
After deployment, User A will use postgresql or perhaps mysql to build a LAMP system. Updates will happen, and either pgsql or mysql will need to rebuild indices on the database store, because there has been a non-compatible bugfix, that is not backward compatible, or something to that effect. Because the database software authors have been burned, they have written documentation cautioning to take and test database backup dumps that may be reloaded, and and indeed also conversion testing scripts that actually attempt to do it 'behind the scenes'. The scripts are robust and will carp and bail if they run out of space, or otherwise fail other sanity checks.
But there is a design decision: is one 'polite' as to filesystem use and pollution, and NOT leave that intermediate dump behind; or is one paranoid and save and age several backups, both for this conversion and generally, because you (the database software author) have been berated by your use community for THEIR failure not to read the documentation and to heed the warning to take and test backups
[Those reading this will note certain parallels to rants by low-formality 'admins' who appear here from time to time -- just a random co-incidence, I am sure]
Then RPM has the reasonable design feature, quite intentionally, of providing access to the full, Turing complete which a shell prompt offers. Anconda does as well.
THAT can provide for dynamic repartitioning, filesystem type conversions, and so on ... How does one 'roll back' from such one-way operations?
The answer of course, is one cannot without 'out of the installation' backups
So I am amused that a person sees the RPM hammer, and thinks every problem looks like a nail, rather than, say, TESTING all variants, so there IS NO NEED for such a 'roll-back' capability; or running virtual instances so a 'prior backup' can be taken, the upgrade performed, and if problems show up -- no problem, just start the prior backup and the undesired 'upgrade' does not hurt at all
-- Russ herrold