Last week I wrote about linux's problems with dependencies and upgrades and promised some suggestions this week.

There are a couple of ideas here to be stolen from (sacrilige) windows which could be a start here, though they aren't my long term solution.

Microsoft takes a different approach to updates, which consists of little patches and big service packs. The service packs integrate a lot of changes, including major changes, into one upgrade. They are not very frequent, and in some ways akin to the major distribution releases of systems like Ubuntu (but not its parent Debian ), Fedora Core and SuSE.

Installing a service pack is certainly not without risks, but the very particular combination of new libraries and changed apps in a service pack is extensively tested together, as is also the case for a major revision of a linux distribution. Generally installing one of these packs has been a safe procedure. Most windows programs also do not use hand-edited configuration files for local changes, and so don't suffer from the upgrade problems associated with this particular technique nearly as much.

There have only been 2 major service packs for 2001's Windows XP. There are software packages that require a user have upgraded to SP1 or SP2, but as noted, a fairly large amount of software typically installs fine on 1999's Windows 2000 or even Windows 95.

I wonder if something akin to service packs might help linux distributions. In most of these cases, a service pack is something very simple -- it's just a set of core packages, tied together, and tested together, and tested with old releases of the distribution.

The typical package in a service pack would be the major libraries (libc, X windows, etc.) and major applications which have more than one or two add-ons that depend on them. Anything that is widely depended on (or which has just one very popular package that depends on it) would make sense in the service pack.

The pack would be assembled and compiled for the most recent release, of course, but also for releases going back several years. Volunteers could also build the pack for releases going back as far as they like.

In addition, a strong push would be made for packages in the pack to have samless upgrade. Where possible, they would be migrated, either by their authors or the distribution maintainers, to divide their configuration up so that configuration by the author, packager and mostly importantly local machine admins and user are never kept in the same file.

If they must be in the same file, scripts should be prepared to help merge changes. These scripts would have access to the virgin configuration files from the package previously installed and the user's latest versin of it, so that they can calculate the differences. They would also have access to the new author/packager version of the file. With all 3 in hand the tool could do a decent job of creating a new merged file applying both the changes by the maintainers and the local changes. This is a similar problem to that faced in version control systems, and in fact these tools might be used for this problem. (Package authors and maintainers might even retain repositories showing all changes on their end, and encapsulte a history of all these changes with a package.)

Of course, ideally one change will be to change the master file to just say "Include localconfig/*" and put all local changes into localconfig, and do it that way from then on. This moves us closer to my eventual goal of dividing configuration according to who does the configuration instead of just what package it is.

At this point, the service pack upgrade should be fairly safe. Others should have tried that exact upgrade before, even on older systems. And new software packages can be installed on old systems with greater ease and less risk. The packs need not be monolithic. All linux package managers can identify packages in a pack that don't need to be upgraded or installed at all. With minor modification they might even record that if anything does come to depend on a package, it should be upgraded to match the pack. The packs, which are simply lists of packages tested together, can also be divided up, so there is one general pack, one for media applications, one for programming and so on.

The temptation must be avoided, however, to turn the pack into a kitchen sink. Otherwise it could turn into something akin to a major release.

Software developers and packagers, of course, should still make an effort to tune their dependencies. They should test and build packages with older releases of libraries and other dependencies unless they know for sure that they need newer ones. Thanks to virtualization tools, such as user mode linux and the low price of disk space, it is also possible to keep around older releases for testing and package building. With a bit of work, if a package says it depends on some late revision of a library, you can suspect it actually means it.

Microsoft's other feature, which they took a long time getting around to, is their tool for XP, the User Migration Tool/Settings Transfer Wizard. That is a tool designed to extract the user's custom settings from one copy of Windows (either older or the same release) and import them to a fresh install. This was not Microsoft's idea of course -- commercial products to do this existed for some time beforehand. Because fresh installs are even more needed in Windows than in *nix, this tool is even more needed there, but it takes us along what I think is the right course -- finding a way to encapsulate the changes an owner makes to a system away from changes made by all sorts of other people (software authors, OS distributions, corporate sysadmins) so they can be easily backed up and transferred. I'll write more about that in the future.