Patch management is part of package management

January 9, 2010

There's two approaches to distributing updates; you can distribute entire new versions of packages, or you can use some sort of 'patches'. For essentially historical reasons, commercial Unix vendors generally use the latter approach.

Here is something important about this: if you have patches, patch management needs to be part of the packaging infrastructure, even if it is not done with the package management system and commands. It cannot and should not be something that is just slapped on over top.

Here's why:

From a sysadmin perspective, the purpose of package management is to keep track of what is on your system; what is there, where it comes from, what it should look like, and so on. (This applies whether or not the packaging system is used for extra software or is only for the base operating system.)

The purpose of patching is to change what's on your system. This is exactly what package management is supposed to keep track of, so that it can give you correct answers to your questions about what should be there and where it should have come from. Ergo, patching needs to be part of package management so that package management can continue to give you these answers, instead of out of date lies.

(Patching is not the only such thing, mind you. As a general rule, current package management systems are utterly lacking in ways for sysadmins to tell them about changes. If it's not a new version of a package, they don't know about it and they don't want to hear from you. I maintain that this is a mistake, but that's another entry.)

Written on 09 January 2010.
« A brief and jaundiced history of Unix packaging systems
Why the Solaris packaging system is bad »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Jan 9 02:25:24 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.