OpenPKG Advent Calendar 2006

Tips & Tricks
Proxy Packages

We the unwilling,
led by the unknowing,
are doing the impossible.

— Larry Wall

Assume you have multiple closely related OpenPKG instances installed on the same system. In this case lots of dependent (and this way required, although not explicitly wanted) packages have to be installed in every OpenPKG instance. Think especially about CORE class packages like openssl, perl, gcc, etc. This can be both very time-consuming and become a maintenance nightmare on upgrades.

Instead, wouldn't it be nice to select a master OpenPKG instance, install those regular packages physically there only and install simple proxy packages for them in all other slave OpenPKG instances?

"openpkg makeproxy" to the rescue

The openpkg makeproxy command of the openpkg-tools packages allows you do this. It creates a proxy binary OpenPKG RPM package for a slave OpenPKG instance by emulating a regular binary OpenPKG RPM package from a master OpenPKG instance.

A proxy package contains (virtually) the same contents as the regular package, but in the form of a shadow tree. Such a shadow tree consists of the same physical directory structure but with all files replaced by symbolic links pointing to the regular files in the master OpenPKG instance.

Keep in mind that this obviously works correctly for packages which do not have hard-coded dependencies to their OpenPKG instance (configuration files, etc). For other packages it might also work, but be at least be warned about side-effects! Additionally, make sure you always keep proxy packages in sync with the regular package by recreating the proxy packages after the regular packages have changed.

Proxy Package Shadow Tree

The shadow tree of a proxy package foo contains the following three types of paths:

slave-prefix[/dir]
This is a physical directory for the slave OpenPKG instance, exactly as it exists in the regular package of the master OpenPKG instance.
slave-prefix[/dir]/file → revdir/.prefix-foo[/dir]/file
This is a virtual file (symbolic link) for the slave OpenPKG instance, indirectly pointing to the corresponding file of the regular package in the master OpenPKG instance. The revdir is a reverse path corresponding to dir, i.e., for each sub-directory step in dir it contains a "../" parent directory step.
slave-prefix/.prefix-foo → master-prefix
This is a virtual file (symbolic link) for the slave OpenPKG instance, directly pointing to the prefix of the master OpenPKG instance. This allows one to redirect a whole package to a different OpenPKG instance by manually changing the slave-prefix/.prefix-foo symbolic link. The idea is that this link even could be automatically controlled by a higher-level facility.

Example

Assume you have three OpenPKG instances on a system: /usr/opkg (the master instance), /v/foo/sw (a project instance) and /v/bar/sw (another project instance). Now let us install the OpenPKG bash package in all three locations, but only once physically.

      # build and install regular binary RPM package for /usr/opkg
      $ /usr/opkg/bin/openpkg rpm --rebuild \
         bash-3.2.1-2.20061019.src.rpm
      $ /usr/opkg/bin/openpkg rpm -Uvh \
        /usr/opkg/RPM/PKG/bash-3.2.1-2.20061019.*.rpm
     
      # build and install proxy RPM package for /v/foo/sw
      # (using the regular binary RPM package of /usr/opkg)
      $ /v/foo/sw/bin/openpkg makeproxy --output=/v/foo/RPM/PKG/ \
        /usr/opkg/RPM/PKG/bash-3.2.1-2.20061019.*.rpm
      $ /v/foo/sw/bin/openpkg rpm -Uvh \
        /v/foo/RPM/PKG/bash-3.2.1-2.20061019+PROXY.*.rpm
    
      # build and install proxy RPM package for /v/bar/sw
      # (using the installed package of /usr/opkg)
      $ /v/bar/sw/bin/openpkg makeproxy --output=/v/bar/RPM/PKG/ \
        --master=/usr/opkg bash
      $ /v/bar/sw/bin/openpkg rpm -Uvh \
        /v/bar/RPM/PKG/bash-3.2.1-2.20061019+PROXY.*.rpm