- if [ $code -eq 104 ] && \ - ! command -v systemctl > /dev/null ; then - # We're not using systemd and thus may have some sysvinit cleanup - # to do in order to comply with policy 9.3.3.1 - - if [ -z "$ENABLED" -o "$ENABLED" = 0 ]; then - # The rc?d symlinks are inconsistent with the value set in - # /etc/default/spamassassin. Update the symlinks to - # reflect the actual state. - update-rc.d -f spamassassin remove - update-rc.d -f spamassassin defaults-disabled - deb-systemd-helper disable spamassassin.service - fi - elif [ $code -eq 101 ] && \ - command -v systemctl > /dev/null && \ - [ $ENABLED -eq 1 ]; then - # We're running on a systemd system, and the service is not - # configured to start (the default), but the admin has - # previously enabled it via - # /etc/default/spamassassin. Preserve that configuration. - deb-systemd-helper enable spamassassin.service - fi
Won't this introduce a similar bug for systemd users who have ENABLED=1 in /etc/default/spamassassin? The expectation is that this setting is preserved by enabling the systemd service if ENABLED=1 is set. noah
