Sam Varshavchik wrote:
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…
It was NOT a binary RPM. It was a heavily tweaked source RPM and would
probably blow up an upgrade. I won't say that definitively, but it's
bloody likely.
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?
I don't know. I don't do emacs and I had to get it done at like 2:00
a.m. to meet a deadline. I buggered the spec with vi and did some
rebuilds. It was dark, they were big....
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.
Yes, you have. And this wasn't meant to start a flame war. All I'm
saying is that yes, it sometimes works (perhaps more often than not),
but sometimes it ends up as a smoking hole in the ground. Be careful.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer rps2@xxxxxxxx -
- Hosting Consulting, Inc. -
- -
- "Hello. My PID is Inigo Montoya. You `kill -9'-ed my parent -
- process. Prepare to vi." -
----------------------------------------------------------------------
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
