Comment 20 for bug 1594740

A minor follow up to my previous comment for anyone else testing this:

Correctly testing the fixed package is a bit subtle because if you simply run 'apt purge supervisor' the symbolic link /etc/systemd/system/multi-user.target.wants/supervisor.service (which was created by a previous manual invocation of 'systemctl enable supervisor') will remain and the next installation of the buggy 'supervisor' package will (confusingly enough) correctly start Supervisor after installation.

To summarize, I used the following commands to test this:

sudo apt purge supervisor
sudo rm /etc/systemd/system/multi-user.target.wants/supervisor.service
sudo apt install supervisor

# At this point, with a `clean re-installation' of the _buggy_
# package, the old and broken behavior that I originally reported can
# be reproduced. This was to verify that I could still reproduce the
# issue with up to date packages. It also confirmed that my manual
# `systemctl enable' invocation hadn't left any state behind on the
# filesystem.

sudo apt purge supervisor
sudo add-apt-repository ppa:nacc/lp1594740
sudo apt update
sudo apt install supervisor

# At this point the Supervisor daemon is correctly running straight
# after installation, without requiring `systemctl' commands from the
# operator.