Skip to content

Call To Action – Upgrading

I spoke to Tim Burke, Director Emerging Technologies (including the linux kernel and Fedora) at RedHat about the state of upgrading this past Tuesday at the GNHLUG meeting in Manchester.

<p>In my experience most of the cost of a Linux system is keeping the thing current and upgrades are essential with Fedora releasing a new test release every six months or so.  In fact, the Fedora Legacy Project exists, largely so people don’t have to upgrade their systems.  It’s that hard.</p>
<p>Well, it’s not really that hard, you can use yum to upgrade between releases, but beyond a few releases it’s sometimes more efficient to isolate your data, install a new system, and then try to integrate your data and configurations into the new system.  The Fedora Core installer doesn’t even support upgrade installations, a feature our Windows friends take for granted.</p>
<p>“So, Tim,” I said, “Why don’t you guys do upgrades?”  “It would make everybody’s life so much easier.”  </p>
<p>The answer is complex, but it roughly comes down to this: The Fedora Project, like Redhat, sees itself as a systems integrator.  They assemble roughly 1200 packages from all over creation and make them work together.  Any of those 1200 packages may require special handling to upgrade from one version to another and the Fedora Project doesn’t have the resources to get them all right.</p>
<p>“So, really what needs to happen is each package maintainer needs to supply an upgrade script with each of their new versions, and then the problem would get much smaller?” I continued to prod.  I’m not sure if The Fedora Project is ready to consider the implications of such a change, but the response I got was that this is the right track should such a thing ever stand a chance of happening.</p>
<p>Some of these upgrades are complex.  For instance, PostgreSQL uses a new binary database format in version 8 than in version 7.  You need to dump your database to disk, make a new database, then reload the database from dump.  And you have to make sure there’s enough disk space to be able to do it.  Does this sound like the kind of detail-oriented mundane work that’s good for a computer to do?  You betcha, but somebody has to write the upgrade script and it’s not a sexy job. </p>
<p>So, I issue a challenge to all package maintainers out there who have their projects integrated into distributions like Fedora - give upgrades a chance.  Distributing this job out to the projects is the only sensible way to lighten the load, and a good method will be useful for all distributions (and non-distribution end-users to boot).</p>
<p>There would need to be some standard calling mechanism, perhaps using make, perhaps using configure, or maybe a new project similar to configure - let’s call it upgrade.  You might call it like:</p>
<p>./upgrade –from-version=2.3.1 –to-version=4.2.3</p>
<p>and be able to pass it all kinds of ETCDIR LIBDIR or INCDIR parameters for each version.  The beauty of this kind of system is it encodes the requisite knowledge for doing an upgrade that is somewhat hard to discern from UPGRADE files, especially for new users.  And if the developers have to take upgrading into account they would take care to make changes in the best way to ease change for their users.</p>
<p>So, this kind of system is inevitable.  Whether it gets started this year, in 5 years, or in 25 years, we’re not going to be without upgrading forever, or linux will be passed by by something else easier to adminsiter.  At some point inclusion into certain distros will list upgrading as a requirement and packages and distros will thrive or perish based on this criteria.   I know I’m going to chose the distro that’s easy to upgrade over the one that wants me to do it all manually.  </p>
<p>This essay is meant to put a bug in your head - keep upgrading in mind for future version releases of your software package.