Hi,
I post this because it might be useful for other Unbound users as well:
we at Men & Mice install Unbound binaries into
/usr/local/unbound-<version>, however the binaries are compiled to run
from /usr/local/unbound. A symbolic link must be set from the current
version installation directory to /usr/local/unbound.
This scheme enables many concurrent versions of Unbound to be installed
by the local packaging system (RPM, DEB, PKG). This eases the testing of
new versions and also a quick roll-back if needed to an previous version.
The script linked below automates the linking, it also provides a quick
way to switch back to previous used version of Unbound.
https://otrs.menandmice.com/otrs/public.pl?Action=PublicFAQ&CategoryID=21&ItemID=97
-- Carsten
I thought this is the use case stow was invented for?
Flo
PS: http://www.gnu.org/software/stow/ or apt-get install stow
Hello Florian,
thanks for pointing out "stow". I was not aware of "stow" (there are
many hidden gems in the open source world).
However after having read the documentation, it seems that "stow" is not
a full replacement for what we do. It seems to install packages (from
source) into its own separate directory (same as we do) and then
symlinking it into the usual directories (like /usr/local/sbin/unbound).
It does no seem to support multiple versions of the same software
installed at the same time, and not switching between versions. "stow"
is also designed to work with source packages, while we work with RPM,
DEB and Solaris PKG for easy binary installations. With "stow"
symlinking into the usual directories, there is also the danger of an OS
update or a manual compilation run to overwrite the links created by
"stow" (or even worse, following the symlinks and alter the original
binaries).
The idea of the Men & Mice packages is to use the OS package system but
to install into a place where the binaries are save for OS updates and
manual installs of the same software. The "switchunbound" script is
rather simple, it just switches one directory symlink.
But "stow" is a good new addition to my toolbox, I'm glad to know about
it (now). Can be useful.
-- Carsten
Stow is simply a simlink management script - It is not bound to /usr/local
but rather manages a directory which is one level up to the "stow" dir ...
And it can manage multiple versions easily as one can remove the links
and restow a different version:
root@p:/usr/local/stow# mkdir -p version-1/sbin
root@p:/usr/local/stow# echo version-1 >version-1/sbin/daemon
root@p:/usr/local/stow# mkdir -p version-2/sbin
root@p:/usr/local/stow# echo version-2 >version-2/sbin/daemon
root@p:/usr/local/stow# stow version-1
root@p:/usr/local/stow# ls -la ../sbin/daemon
lrwxrwxrwx 1 root staff 29 Nov 21 14:37 ../sbin/daemon -> ../stow/version-1/sbin/daemon
root@p:/usr/local/stow# stow -D version-1
root@p:/usr/local/stow# stow version-2
root@p:/usr/local/stow# ls -la ../sbin/daemon
lrwxrwxrwx 1 root staff 29 Nov 21 14:38 ../sbin/daemon -> ../stow/version-2/sbin/daemon
So simply build you project and install it with
prefix=/usr/local/stow/project-version and then stow it ... stow is very
good in eliminating whole subdir trees by symlinking directories as long
as they are unique to a specific project stowed in that basedir.
Its very generic and i also use it for managing different versions of
self compiled binarys in my homedir ...
Flo