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