Redhat 8 to 9

[Panu Matilainen]

On Thu, 10 Jun 2004, Eric Rostetter wrote:

> Quoting Panu Matilainen <pmatilai at welho.com>:
> 
> > There are couple of important things that make for a smooth apt-upgrade:
> > - Use a version which uses rpmlib for the transaction processing. That
> >   makes all the worlds difference for the safety of the upgrade, you wont
> >   be left with a system without glibc that way.
> 
> It would simply refuse to upgrade for me because of glibc.  So I had to
> upgrade glibc manually, then do the dist-upgrade.  It in no way removed
> glibc from my system...

That sounds REALLY weird.. but ok I've seen some weird stuff happen with 
older apt versions. The "remove glibc" is one of those "seen freaky things 
happen" with old apt-versions because they did
rpm -e <bunch of stuff>
rpm -Uvh <the rest of stuff>

which could result in really nasty mess if the rpm -Uvh step happened to 
have for example file conflicts and abort. Hence the *heavy* 
recommendation of using a version of apt which uses rpmlib for transaction 
processing where things like that can not happen.

> 
> > - Make it use rpm's ordering instead of it's own on any RH-oriented
> >   distribution: set 'RPM::Order "true";' in /etc/apt/apt.conf. Apt's
> >   internal ordering works more reliably for Conectiva but then they
> >   have different packaging standards...
> 
> Now that is interesting news to me. I'll have to check it out.

Doesn't make much of a difference for most dist-upgrades but for example 
FC1 -> FC2 upgrade is an utter disaster with apt's own ordering (that's 
how I found out apt's again using it's own ordering, my original rpmlib 
support used rpm ordering because of this)

> 
> BTW, I've done one real apt-get upgrade on a real server, and that is all
> I really plan to do.  I really needed to mimimize downtime, and the apt-get
> upgrade worked and made my total downtime just a few minutes for the reboot
> (needed to get the newest kernel loaded after the upgrade of course).
> 
> All the other apt-get upgrades I've done have been done more for
> curiousity/experimentation/etc.  I don't recommend doing this kind of
> thing in general, but there are cases where it may be called for (like my
> one single server upgrade) due to downtime requirements, etc.

I've had to *support* doing upgrades for years now because our laptop 
users have encrypted disks, root and all so anaconda wont do... Been "fun" 
an times :)

> 
> I'd recommend not doing this until you test it on a test machine or two.
> Once you are comfortable on a test machine, then try it on your server.
> Don't make your server your test machine!

Yep. It's generally quite safe to do, or lets say not really any unsafer
than upgrading with anaconda for any given RHL (upgrade to FC2 is another
issue) but it's certainly a good idea to try it out on a
similar-to-production test system for the first times.

	- Panu -