On 30 December 2016 at 22:14, Dmitry Smirnov <only...@debian.org> wrote: > On Tuesday, 20 December 2016 9:32:18 PM AEDT Felipe Sateler wrote: >> Moving >> the removal to after the debhelper block should fix this as well. > > Would that be an ugly workaround for bug in the other package? > > >> Upon package remove but not purge, dh_systemd will mask the unit so >> that upon the next boot you do not get boot failures because the >> program is no longer installed. > > I still do not understand how/why is that a problem in gfarm (but not in > other packages) and why gfarm needs workaround. > > It still looks like a bug in debhelper. Could you please elaborate why you've > reassigned this bug back to gfarm?
Because gfarm, unlike other packages, removes the file /etc/systemd/system/$foo.service. The debhelper-systemd machinery does the following: 1. Upon package removal, remove the file /etc/systemd/system/$foo.service if it exists, and records that fact in a state file (/var/lib/systemd/deb-systemd-helper-masked/$foo.service). This is done to prevent the service from being brought up during boot when the package is removed but not purged (see policy 9.3.2 for the analogous recommendation for sysvinit scripts). 2. Upon purge, if the file /etc/systemd/system/$foo.service exists, is a symlink to /dev/null, and the corresponding state file exists, both the state file and and the link are removed. Because the gfarm postrm script deletes the service file in /etc, step 2 is not done, and the state file is not deleted. I hope this makes it clear why I think this is a bug in gfarm. If you really want to remove the file in /etc (which I'm still not sure why would you want to), you should do so after the debhelper machinery has done its work. -- Saludos, Felipe Sateler
