test -[fxe] in init scripts, removed-but-not-purged
Eloy A. Paris and I have been working on providing dhcp 3.x packages for
unstable. Since the new upstream release is a beta, and dhcp is a very
important package for installation and many everyday applications, we would
prefer not to replace the 2.x packages just yet. We do, however, want to
provide both packages in woody, side by side, to allow users to try the 3.x
packages where appropriate.
We have run into many problems in supporting a smooth upgrade from the 2.x
packages to the 3.x packages.
For example, the user might have a removed (but not purged) version of the
2.x packages on their system when the 3.x packages are installed. This
would be quite common, since users would migrate from dhcp -> dhcp3-server,
which would typically remove (but not purge) dhcp. This means that the user
will have an /etc/init.d/dhcp which is configured to start /usr/sbin/dhcpd
if it exists. Naturally, the 3.x packages also provided /usr/sbin/dhcpd, so
this would cause init to try to start dhcpd twice. This is unpleasant to
say the least. The only solution seemed to be to rename dhcpd in the new
packages, which we did.
Now, there is a similar, but trickier problem with dhcp-client. Older
version of dhcp-client also provided an init script with the usual test for
/sbin/dhclient. This was renamed, also, but this breaks ifupdown, which
makes the dhcp3-client package much less convenient to test.
I'm sure that others must have dealt with this situation before. What is
the best current practice? It seems like the fundamental problem is that
the usual "test -x /my/program" idiom is insufficient for testing whether a
given package is installed, since distinct, conflicting programs can both
provide that file while the init script is still on the system. These init
scripts must not run unless the package is actually installed and
Do we need a more robust method for ensuring that a package is installed in
(of course, this wouldn't help dhcp, but in the future...)