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...
- 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.
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'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!
- Panu -
-- Eric Rostetter
-- fedora-legacy-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-legacy-list
