On Mon, May 17, 2021 at 07:57:23PM +0200, Guillem Jover 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.
Yes, you're correct. The code you deleted in your patch should have been removed a long time ago. (really multiple releases ago, but that's ok) noah
