Upgrading busy systems

I’ve discovered a few inconvenient factors in upgrading a busy system — live.

Yes, it can be done.

But it’s not as simple as telling URPMI to upgrade everything it wants to, because then it swiftly consumes heaps of RAM (1.6GB, in this case) & then grinds to a halt as it starts to swap in search of even more RAM in order to sort out the competitive requirements of thousands of packages in one go.

My way around this has been to tell it to upgrade everything, then stop it before it does the actual upgrades, select a smallish chunk (maybe 50-100MB) of packages, & tell it to upgrade just that.

This works well until you select something which has some heavy requirements.

My bugbear here has been the X system, which includes the basic services, drivers for a zillion video chipsets, & countless X utilities which are dependent upon the version of X itself.

I have in mind a few key packages that it asks for as a part of this set of dependancies, and when I see one of those come up, I deduce which package(s) asked for it & try the chunk again without them.

This has the added advantage of interrupting only one or two services at a time, and that for short periods, whereas if it were to try upgrading the whole collection en-bloc, it might remove the old services early, & install their replacements late — or discover that a package it’s removing is internally dependent on some particular files etc belonging to another package, so remove the old one & not install a replacement.

With short install blocks, I get a detailed listing of the conflict, & to quickly identify the problem-child, remove it & its dependencies, & then “hand-install” a replacement. Also, I typically only lose one or two tools at a time; for example, vi unexpectedly expired for lack of a PERL library at once stage, so I simply used another editor while I found a useful replacement for the library.

Aaanyway... down to 2.55GB & 1420 packages now, & proceeding carefully.