Patch Management/Code11

From openSUSE

Code11 patch & update

This pages describes the basic concept of patch & update for Code11.

Caveat empor

This page describes the concept. Not all of this is implemented in openSUSE 11.0 and some of it may never be.

Terminology

This is the terminology used in the description below.

• Update - a single replacement (newer version of a) package
• Patch - information about updates, esp. severity and grouping

Problem statement

rpm only

Maintenance with 3rd party (package mgmt) tools. Our tools give additional information resp. usability/functionality but there is no lack of completeness when using plain 'rpm'.

Especially switching between 'rpm only' and SUSE tools is explicitly supported. The SUSE tools will give better (automated) functionality. Using 3rd party tools might require additional manual steps (like running a script or adding a repository) to keep the system fully maintained.

Updates only

Based on the 'rpm only' requirement, the easiest approach seems to be just to install every available update. This choose newest package is indeed the way for most package based tools and how rpm -F (freshen) is implemented.

The main problem with this approach is possible dependency problems. The typical case is kernel and driver, but it applies to any dependent packages. Imagine an installed kernel together with a 3rd party kernel driver. If the kernel vendor has to push out an security update which breaks the driver ABI, you better have the matching driver available. But this requires exact timing. You can't update the kernel without the updated driver and vice versa.

Mixing patches and updates

Patches provide additional information on updates and group updates. This effectively hides updates from the users (default) view and puts the fixed bug in the foreground.
Example:
Instead of showing update for e.g. glibc, glibc-locale, glibc-info, glibc-devel, glibc-i18ndata, glibc-32bit, glibc-locale-32bit, glibc-devel-32bit (typical for a 64bit system when glibc is updated) one just sees a single Security fix for system library (glibc).

This is nice when patch information is available for all updates. However, this is not the case with 3rd party repositories. So pure updates (no patch information available) must be included in the view.

The concept is to generate 'fake' patches with a normal severity. This is currently not implemented in openSUSE 11.0.

Triggering updates

The existence of 'patches' and 'packages' also raises the question of 'what triggers the update' ?

Traditionally, patches are the update triggers. Based on available patches with unfulfilled requirements, the application (yast, zypper, packagekit) selects which updates (packages!) to install.
Although this works fine with most SUSE updates, it does not take 3rd party updates (no patch information) into account.

This is still unsolved in openSUSE 11.0 due to a limitation of internal data structures and semantics. If one wants to install updates, zypper update -t package gives this functionality on the commandline.

Patch levels

After release of a distribution, problems get fixed and updates are released. There is no fixed update schedule, updates get released when the problem is solved and the fix tested and verified.

This constant flow of updates makes it hard to take a snapshot or to define the state of the system. One can only give a full list of installed packages.

Sometimes it is extremely useful to recreate a specific state. Deploying a certified (against specific package versions) 3rd party application this is even mandatory.

Beginning with Code11, patch levels should be possible together with functionality to bring a system to a specific patch level and lock down.

Concept

Changes compared to Code10

• No freshens !
  • The need for update is determined by the package. Either by
    • higher version (normal update)
    • provides/obsoletes (rename update)
    • provides name > version (downgrade, see Fedora packaging rules)
• No Atoms !
  • patch just groups packages and provides description
  • groups are per-architecture
  • application layer filters architecture, not solver
• Patches are noarch
  • patches are generic 'update entities'
  • normally not bound to a specific architecture
  • arch-specific patches are the exception, not the rule

rpm only

• Patches are optional
  • no influence on maintenance / updates
  • patches are added value, not core value
  • easy to create in autobuild
  • easy to create by customer !

• Patches are not installed
  • Updated packages are installed
  • Patches are satisfied
  • (A set of) updated packages match a patch. This satisfies the patch

Updates only

The solution is twofold

1. choose the best package, not necessarily the newest one.
2. do not blindly update every package but compute a working set of updates.

Luckily, the Code11 dependency solver provides this functionality.

Mixing patches and updates

• Patches are no solvables (don't have dependencies)
  • there is no need to
  • patches are just information, if deps would be needed they have to be reflected in the package deps

Triggering updates

• Patches dont trigger the update, packages do
• Let the dependency solver compute a possible update set (best updates for the system)
• Match patch information to this set
• Packages without matching patch information get a 'normal' severity

Patch levels

• Patch levels require sequential ordering of updates
  • A level must be unambiguous, independent of available repositories
  • sequence can only be determined per-repository, if this is not a 100% solution

Open points

• Trigger
  • openSUSE 11.0 still uses patches to trigger updates
  • by default, only updates with patch information are installed
  • use zypper up -t package to install 3rd party updates
• Patch level determination
  • per repository / product
  • autobuild will generate timestamps (not levels)
• Patch level lockdown
  • this isn't implemented yet