[Piuparts-devel] Need help with a particular piuparts run

Michael Stapelberg stapelberg at debian.org
Mon Jul 1 22:09:48 UTC 2013


Hello dear piuparts developers,

I recently noticed that one of my packages, kanla, had a failed piuparts
report:

http://piuparts.debian.org/sid/fail/kanla_1.3-2.log

This in turn is caused by init-system-helpers, which I maintain. It
contains a script, deb-systemd-helper, to enable/disable systemd service
files on any machine, regardless of whether it is actually running
systemd as PID 1 or not (in that way it differs from systemctl, which
you’d normally use for that job).

Now, there’s two parts to that report:

1. The empty directories /etc/systemd/**/* and /var/lib/systemd/**/* are
   not cleaned up by init-system-helpers after purging. I have a fix for
   that ready, but it is blocked on 2:
2. The file
   /var/lib/systemd/deb-systemd-helper-enabled/kanla.service.dsh-also
   is not cleaned up either.

Point 2 blocks point 1, because it prevents the directory from becoming
empty.

The reason why point 2 happens is because kanla calls
init-system-helpers’s “deb-systemd-helper disable kanla.service” in
kanla’s postrm script on purge. However, piuparts already removed
init-system-helpers _before_ purging and therefore, the call is not
made, thus the state file is not removed, thus the directory cannot be
cleaned up.

We cannot delete this state file at package removal time because we want
to preserve state across package reinstalls (e.g. “apt-get install kanla
&& systemctl disable kanla.service && apt-get remove kanla && apt-get
install kanla” should result in a still-disabled kanla.service).

I have noticed that this does not fail on my machine with a chroot
generated by debootstrap because rsyslog is installed in that chroot,
and rsyslog depends on init-system-helpers, so piuparts will not remove
it.

This case (the package being present at all times) is most likely how
reality will look like. I therefore consider the piuparts report in this
case not very helpful, but rather misleading for the maintainers of
otherwise unrelated packages, like e.g. kanla.

Is there anything we can do about this situation?

Thanks!

-- 
Best regards,
Michael



More information about the Piuparts-devel mailing list