OpenPKG: shift gear to CURRENT
OpenPKG development has been shrunken to CURRENT. Here is how I recently switched a lot of instances running releases and snapshots version to CURRENT.
It is a good idea to backup the whole instance first. Often a valuable backup requires shutdown of the services during backup. Run “~openpkg/bin/openpkg rc all stop” first. The upgrade will likely modify configuration files. You know the changes you did, eh? I’ll write another article on that topic.
switch to the management user
# su - openpkg
look which bootstrap the instance is running
$ openpkg rpm -q openpkg openpkg-20050403-20050403 # current (maybe old, however) openpkg-2.20070605-2.20070605 # snapshot openpkg-2.5.3-2.5.3 # release openpkg-E1.0.3-E1.0.3 # enterprise
look which release and download are detected or have been configured
$ openpkg release OpenPKG-CURRENT ftp://ftp.openpkg.org/current/SRC/
In order to successfully download, build and install packages you need a recent version of “openkg build”. Before 2006-08-11 this tool was available only by installing “openpkg-tools” package, since then it already ships with the bootstrap. In case openpkg-tools is installed it takes precedence. That means that a recent bootstrap combined with an ancient openpkg-tools package will give you the outdated “openpkg build” commands. The easy rule is to always install the most recent “openpkg-tools” from CURRENT, then switch the bootstrap to the latest CURRENT version and remove the “openpkg-tools” package unless needed for unrelated tasks. The enterprise version always shipped “openpkg build” with the bootstrap. You can identify a recent version by running “openpkg build –help” and watching out for -k option to “keep temporarily downloaded packages”. If it exists, “openpkg build” is recent.
In order to successfully install packages as management user you must run a bootstrap recent enough to support the SUID feature.
$ ls -l ~/bin/openpkg -rwsr-xr-x 1 root openpkg 17768 2007-03-26 21:10 /openpkg/bin/openpkg
The u+s flag must be set and the user must be “root”. If this is not the case you must not blindly pipe the output of “openpkg build” into the shell but redirect to a file and edit it to disable the line with “openpkg rpm -Uvh openpkg-*-.rpm”. My preference is to prefix the line with an echo so I can copy+paste it.
download and rebuild the bootstrap from the CURRENT repository
$ openpkg build -r ftp://ftp.openpkg.org/current/SRC/ -kKbBg openpkg | sh
The “| sh” is for optimists, I prefer to replace it with “| tee x; read DUMMY; sh x” 
In case your bootstrap is old enough to not support the SUID feature you have disabled the “-Uvh” line. Exit from the management user shell back to the root and run the command as privileged user. Then switch to the management user again.
With a CURRENT bootstrap it’s time to get rid of “openpkg-tools”.
$ openpkg rpm -e openpkg-tools
Also we can stick to “openpkg release” defaults
$ mv ~/etc/openpkg/release ~/RPM/TMP/
look what the instance is running now
$ openpkg rpm -q openpkg openpkg-20070623-20070623 $ openpkg release OpenPKG-CURRENT ftp://ftp.openpkg.org/current/SRC/
In almost all cases an OpenPKG instance uses it’s own development chain, starting with the famous triple make, binutils, gcc. Make sure these are updated first in exactly that order. Everything else depends on them and depending on the age of the instance it is likely it runs an old version of these critical tools.
$ openpkg build -kKbBg make binutils gcc | sh
Finally, we can upgrade the rest of the instance. Make sure to tell the “openpkg build” logic to start from zero and ignore the existing packages. This is important because it ensures a certain build order. If you forget to start from zero, existing packages are utilized to fulfill requirements. This means, for example, that a requirement like “postfix::with_ssl requires openssl” allows rebuilding the new postfix against the old openssl and later on rebuild openssl for no useful effect. The root cause of the problem is that the requirement would need to be more specific but the features rpm is offering and the numbering scheme OpenPKG is using do not allow this right now.
$ openpkg build -kKbB -ZUa | sh
Depending how big the step was forward some *.rpmsave files may have been generated. You must resolve them manually and restart the affected service. Note that the “openpkg rc” system chokes on *.rpmsave files and does not allow to start, restart or even stop services unless the problem is resolved. This is a feature - you don’t want to “openpkg rc openssh stop” or restart just to find out it won’t come back online.
find out the problematic files
$ openpkg rc all status
…
$ vi ~/etc/foo/foo.conf
$ openpkg rc foo stop start
To reduce downtime you may build most of the packages but defer installation of leaf daemon packages, those daemons controlled by the “openpkg rc” mechanism who are at the end of the dependency chain and are not a prerequisite for others. Find them using
$ for i in `openpkg rpm -qf \
\`grep -l ^%start ~/etc/rc.d/rc.*\` --qf '%{name}\n'`; do \
openpkg rpm -q --whatrequires $i >/dev/null || echo $i; done
Then find their “openpkg rpm -Uvh …” lines in the output from “openkg build” and comment them out. At the end of the process, handle them one by one. Stop it, install it, resolve configuration file issues and start it.