Patch Management

From openSUSE

Patches

System setup

An installed system consists of packages which contain files. The system setup is determined by all files on the disk(s). Ideally, the set of installed packages defines the system configuration completely.

However, the system setup also includes files which are not related to packages. Everything below /etc/sysconfig is an example.

But even with all files, the system is not described completely. One must also take the environment the system operates in into account. How users interact with it, what network resources it uses or provides, etc.

Bugs

If the system does not behave correctly (read: has a bug), the system setup must be changed. Either the installed software, the configuration, or its setting in the operation environment.

Defining Change

In order to define and track such changes cleanly, we need a crisp definition of change. Thats were patches come into play.

A patch defines a change to the system. There are two classes of changes, those related to files and those not related to files. The latter can be an advise to the user of the system to adapt his 'use pattern' in order to prevent failure.

Applying change

Changes can be applied automatically or manually. Some changes must be applied manually in order to ensure data consistency (i.e. restart of an application).

Most of the changes can be expressed by RPM packages. Changes to non-packaged files can be applied by scripts. These could be RPM scripts, but they don't really belong to any package. RPM scripts also can't be controlled very good and failures of uninstall scripts go completely undetected.

The real problem is non-automated changes, like change in user behavior or restart of applications. Here a message to the system administrator (which must be acknowledged) is the best approach we can currently think of.

This all can be viewed as follows:

(*) Manual changes to files shouldn't be needed since they're too error-prone. A combination of message and script is a better solution.

Why not (updated) packages?

Why not relying on updates packages only you might ask. With the exception of messages, package updates are indeed sufficiently expressive to apply the above mentioned changes.

However, package updates only are unfriendly from a UI perspective because they fail to

• show the reason
  

You certainly want to know if the update plugs a critical security hole or is just cosmetic (e.g. a typo). This is critical information usually not contained in a package

• post-update actions
  

Some updates need specific actions after they're applied. The typical example is a kernel or glibc update which requires a reboot to take effect. Updates to other components (e.g. the update stack itself) might need a restart of this component.

• make the change visible
  Package managers show the package name, version, and summary. Maybe the description. Neither of these contain a description of the change. It might be in the package's changelog, but its costly to retrieve and hard to read.
• group updates related to a change
  If multiple packages need to be updated, either because all of them contain a fix or dependencies require a combined upgrade, its not visible in a package management application.

Having patches as first class software elements with proper software management application support addresses these shortcomings. The patch summary and description concentrate on the bug fixed, package names and versions are of secondary interest. Patches also group related package updates and make the change more visible to the administrator.

Implementation

Code9

Code9 (SUSE Linux 9.x, SLE9) provides updates (updated RPMs) through patches. Patches are used as containers, including metainformation (patch severity, description, etc.) and (links to) the new RPMs. There is no way to access the RPMs without the patch.

It also treats patches and their RPMs as single, self-contained entities. This has two shortcomings

• No dependency resolution of packages. All dependencies must be contained in the patch.
• No support for 3rd party tools. Updates can only be applied through yast-online-update

Code10

Code10 (openSUSE 10.x, SLE10) separates patches (delivering metainformation) and updates (newer RPMs). This separation allows retrieval and installation of package updates with 3rd party tools, without need for patches. It also supports full dependency resolution, allowing an update package to drag in additional dependencies.

However, package updates and patches (referencing package updates) don't mix and match very well. This is caused by the ZENworks based update stack, relying on a central authority (the ZENworks Linux Management server) only providing matching updates. This way, the Code10 update stack can 'blindly' install any available updates without the fear of dependency conflicts.

But the real world isn't that easy and 3rd party repositories can easily spoil the party. This is why Code10 only looks at those updates accompanied by patch metainformation. Both rug and zen-updater default to 'patches only' in their update views.

Code11

Code11 (openSUSE 11.x, SLE11) separates patches (delivering metainformation) and updates (newer RPMs) even further, making patch metadata completely optional (convenience) information. See Code11 Patch & update for a complete description.