OpenPKG Advent Calendar 2006

Monday 2006-12-18: Tips & Tricks
OpenPKG Instance Updating & Upgrading

There are two typical maintenance tasks to be performed on an OpenPKG instance in the long-term:

Updating

Regularily you have to update it. At least every time a security issue is fixed by the release of security fixed update packages. But how to correctly upgrade an OpenPKG instance? There are two approaches:

      # update the complete and slow way
      $ /openpkg/bin/openpkg build -Ua | sh

      # update the incomplete but fast way
      $ /openpkg/bin/openpkg build -Uaq | sh

The first approach is the correct way as it completely updates all affected packages, i.e., it builds and installs the updated packages and also rebuilds and reinstalls all packages which depend on the updated packages. This means all package dependencies are checked in the reverse direction because, for instance, if zlib is updated, both png and imagemagick have to updated as imagemagick depends on png and png in turn depends on zlib. This is necessary because of OpenPKG's static library linking, but it is also necessary for similar "information embedding" between packages. The drawback of this correct way of updating is that is rather slow as usually lots of packages have to be rebuilt.

The second approach is the incomplete but fast way. Although it follows the dependencies and correctly updates according to their topological order, it explicitly does not follow the dependencies in the reverse direction. Hence it updates only the really updated packages. But as a side-effect it does not rebuild the packages which depend on the updated packages.

But why can this incorrect way of updating be useful at all? Think of someone who runs an OpenPKG-CURRENT instance on a development machine and updates this instance once or even twice per day anyway. There it is from a security point of view acceptable to update not the really correct way and because of the often updates it is also not really required to rebuild all dependencies on each small change as they get indirectly rebuilt on their own update soon anyway. So, this is certainly a risky approach, but it can be acceptable for particular environments.

Upgrading

Every four months for 2-STABLE and once per year for E1.0-SOLID, you have to perform a major update — also known as an upgrade. There you switch to a completely new set of packages from a new snapshot or release. But here again the question is what the correct approach is? We recommend the following procedure which upgrades the whole OpenPKG instance, in correct package dependency order and by especially keeping all chosen build-time options sticky: (example shows how to upgrade to 2-STABLE-20061018):

      # upgrade the bootstrap package
      $ /openpkg/bin/openpkg build \
        -r ftp://ftp.openpkg.org/release/2.20061018 openpkg | sh
    
      # upgrade the tools package
      $ if  /openpkg/bin/openpkg rpm -q openpkg-tools >/dev/null; then \
            /openpkg/bin/openpkg rpm -e openpkg-tools; \
            /openpkg/bin/openpkg build openpkg-tools | sh; \
        fi
    
      # shutdown all services
      $ /openpkg/bin/openpkg rc all stop
    
      # upgrade all packages
      $ /openpkg/bin/openpkg build -ZaKB | sh
    
      # resolve configuration upgrade conflicts
      $ find /openpkg/etc -name "*.rpm*" -print
      $ cd /openpkg/etc/package
      $ diff -u3 file.rpmsave file | more
      $ vi file.rpmsave
      $ cp -p file.rpmsave file
      $ rm -f file.rpmsave
    
      # check integrity of instance
      $ /openpkg/bin/openpkg rpm -Va
    
      # start all services again
      $ /openpkg/bin/openpkg rc all start