On Mon, 2021-05-17 at 10:41:28 -0700, Noah Meyerhans wrote: > - 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.
Given that /etc/default/spamassassin does not set ENABLED anymore, by default on systemd systems that code block would no longer run. If the admin had not updated the conffile (due to local changes) to remove the variable (and thus the block would still run now), the code block would have already taken effect in the previous stable release to set the desired outcome (and preserve the state). So it seemed safe to me to remove both as part of the ENABLED variable deprecation process. Thanks, Guillem
