I think any fix for this bug that relies on preserving the old behaviour of /etc/default/firehol is the wrong approach. I had a look through Debian Policy Manual Section 9.3: System run levels and init.d scripts; here’s some snippets:
"This extra file [/etc/default] should be sourced by the [init.d] script when the script runs.” "If [...] the daemon should not be autostarted unless the local administrator has explicitly requested this, [...] add to your postinst script, 'update-rc.d package defaults-disabled', and add a dependency on init-system-helpers (>= 1.50), which introduced the defaults-disabled option. Then the local administrator can enable autostarting the daemon…." "An older practice, which should not be used, was to include a line like DISABLED=yes in the package's /etc/default file. The package's init script would not start the service until the local system administrator changed this to DISABLED=no, or similar. The problem with this approach was that it hides from the init system whether or not the daemon should actually be started, which leads to inconsistent and confusing behavior: service <package> start may return success but not start the service; services with a dependency on this service will be started even though the service isn’t running..." I believe the correct solution would be: 1. Upon package upgrades, check for existing /etc/default/firehol and enable or disable the systemd unit according to the existing $START_FIREHOL value. 2. For fresh installs, systemd unit should ship as disabled. 3. Remove the /etc/default/firehol config file. 4. Remove the /etc/init.d/firehol script. 5. Update the documentation. ;-) I am willing to work on that but it’s unlikely to be any time soon. -mn
