Good for a chuckle

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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

_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos


[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux