OpenPKG Advent Calendar 2006

Every OpenPKG package containing configuration files has those files explicitly tagged as %config in the package specification to allow them to be edited by the administrator and specially handled during a package update to as best as possible keep the edited file in place or at least preserve its content. The approach used by OpenPKG RPM is a rather clever one if one looks at it in detail. In short, OpenPKG RPM's configuration file update strategy can be summarized with the following table:

    old in   old on     new in   new on 
    package  filesystem package  filesystem approach
    ======== ========== ======== ========== ===========================================
    X        X          X        X          keep old config
    X        X'         X'       X'         keep old config
    X        X'         X        X'         keep old config
    X        X          Y        Y          install new config
    X        X'         Y        Y          install new config, preserve X' as .rpmsave
    -        X          Y        Y          install new config, preserve X  as .rpmorig

Here is what this means in detail:

• Nothing changed at all
  This is the trivial case: neither the administrator nor the packager have changed the content of the configuration file. As a result OpenPKG RPM just keeps the old configuration file content as is.
• Administrator and packager changed content identically
  This is surprising but still simple case: the administrator changed the configuration file on the filesystem the identical way the packager changed it in the new package. As a result OpenPKG RPM just keeps the old configuration file content as is.
• Administrator changed content
  This is the usual and also simple case: the administrator changed the configuration file on the filesystem while the packager has not changed it at all in the new package. As a result OpenPKG RPM just keeps the old configuration file content as is, because there is no need to upgrade to the file content in the new package as OpenPKG RPM assumes that the administrator still wishes the same changed to be applied anyway.
• Packager changed content
  This is another usual and also simple case: the administrator has not changed the file on the filesystem at all, but the packager changed it in the new package. As a result OpenPKG RPM just installs the file content from the new package.
• Administrator and Packager changed content differently
  This is the complex case which inherently cannot be resolved automatically: the administrator changed the file content on the filesystem differently to what the packager did in the new package. OpenPKG RPM cannot decide whether the administrator version, the packager version or a mixture of both is required.

  Hence, to at least assure package consistency (the configuration file fits the program) it installs the packager's version of the configuration file from the new package, but preserves the administrator's old version of the configuration file on the filesystem by renaming it from file to file.rpmsave. The administrator now has to decide whether to drop its old version, replace the version of the new package with its old version again or to merge the two versions. In practice one usually have to merge the two configuration files manually and then remove the old file.rpmsave file.

• Administrator and Packager created content differently
  This is a second complex case which inherently cannot be resolved automatically: the administrator created the file content from scratch on the filesystem differently to what the packager did in the new package with a new file. OpenPKG RPM cannot decide whether the administrator version, the packager version or a mixture of both is required.

  Hence, to at least assure package consistency (the configuration file fits the program) it installs the packager's version of the configuration file from the new package, but preserves the administrator's old version of the configuration file on the filesystem by renaming it from file to file.rpmold. The administrator now has to decide whether to drop its old version, replace the version of the new package with its old version again or to merge the two versions. In practice one usually have to merge the two configuration files manually and then remove the old file.rpmold file.

As you can see, OpenPKG RPM in four of six cases reasonably and fully automatically resolves the problem. And even in the remaining two complex cases, it ensures that the administrators file content is not lost.

Notice that "openpkg rc" denies to start or stop packages which have *.rpm* files in their prefix/etc/package/ directory in order to force the administrator to take action and to avoid security issues (which could happen by starting a program with a default configuration).