Looking Ahead - Upgrade

[Sam Varshavchik]

Rick Stevens writes:

> Sam Varshavchik wrote:
>> Rick Stevens writes:
>> 
>> The only problems you'll ever have will not be as a direct result 
>> of the upgrade, per se, but rather the new stuff occasionally not 
>> plainly working. I recall one upgrade, I think it was Red Hat 5, that 
>> loaded a kernel that had a bug that caused a complete freeze, and that 
>> was triggered only on certain hardware, and I won the lottery. That 
>> caused a little bit of excitement. Of course, a fresh install won't make 
>> much of a difference here.
>> 
>> The rules are pretty simple:
>> 
>> * Do not install stuff manually, cowboy-style. Always use rpm to install 
>> software packages, instead of crossing your fingers before running 'make 
>> install'.
> 
> Not always possible.

Oh? Since when did both emacs and rpmbuild stop working, preventing the 
creation of an appropriate spec file, and producing the rpm packages?

>                        I recently had to put OpenSSL 0.9.8g on a CentOS
> 5.1 machine to pass a certain certification.  The latest OpenSSL for
> CentOS 5.1 is 0.9.8b (farking ancient).  I did it by building it from
> a F9-Preview source RPM, building it (with some tweaks as F9 has some
> ciphers that CentOS 5.1 doesn't have),

So you were able to install the software via rpm. So your point is…

>                                        installing the binaries and
> poking various symlinks and such to make existing apps happy.

Was there some bugs in emacs that prevented you from putting those 
symlinks into the spec file?

>                                                                So, Rule
> 1 can't ALWAYS be adhered to, no matter how "stock" you want your system
> to be.

Well, in 13+ years I've managed to adhere to the rule without much of a 
problem. And that included patching out the kernel bug I referenced in my 
previous message.

>> * Know your software. If you're running MySQL or Postgres, dump your 
>> database before the upgrade. Major dot-releases of Postgres will often 
>> refuse to boot up with the previous release's database. You'll need to 
>> nuke your entire DB, start Postgres and have it initialize a fresh DB, 
>> then load your dump. Other major software packages may have their own 
>> idiosyncrasies.
> 
> The fact you've had good luck in upgrades is (to be honest) a bit
> anecdotal.  There have been many, MANY people with completely stock
> systems that have crashed and burned BIG time.  Even Red Hat doesn't
> recommend an upgrade more than 2 revs up (e.g. F7-->F9).

Well, I gues I've been lucky then, upgrading from one release to another, 
for 13+ years, with multiple machines containing wide varities of hardware.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20080509/76e5ef95/attachment-0001.sig>