[Pkg-systemd-maintainers] Bug#715060: piuparts errors: unowned files left after de-installation

[Andreas Beckmann]

On 2013-11-06 19:34, Michael Stapelberg wrote:
> The output for me is now:
> piuparts --do-not-verify-signatures --pbuilder \

> 0m43.4s ERROR: FAIL: Package purging left files on system:
>   /etc/systemd/	 not owned
>   /etc/systemd/system/	 not owned

> Why does the version running at piuparts.debian.org still show these
> other directories? Is this a mistake in the setup, or am I missing
> something?

Do not use the pbuilder chroot, its not minimal enough :-)
Let piuparts create the chroot ... and you should see the error :-)
(-s to save a tarball, -b to use it)

> Other users repeatedly come up with questions about this, too, see
> http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2013-November/000706.html
> for the latest example. So I’d be happy if we could finally fix this :).

the Contents file lists the following entries in /etc/systemd:

etc/systemd/bootchart.conf                              admin/systemd
etc/systemd/journald.conf                               admin/systemd
etc/systemd/logind.conf                                 admin/systemd
etc/systemd/system.conf                                 admin/systemd
etc/systemd/system/dbus-org.freedesktop.Avahi.service   net/avahi-daemon
etc/systemd/system/dbus-org.freedesktop.Hal.service     admin/hal
etc/systemd/system/getty.target.wants/getty at tty1.service admin/systemd
etc/systemd/system/multi-user.target.wants/avahi-daemon.service
net/avahi-daemon
etc/systemd/system/multi-user.target.wants/avahi-dnsconfd.service
net/avahi-dnsconfd
etc/systemd/system/multi-user.target.wants/remote-fs.target admin/systemd
etc/systemd/system/sockets.target.wants/acpid.socket    admin/acpid
etc/systemd/system/sockets.target.wants/avahi-daemon.socket net/avahi-daemon
etc/systemd/system/vsftpd.service                       net/vsftpd
etc/systemd/user.conf                                   admin/systemd


Without having used dh_systemd or init-system-helpers myself, I think
the following happens: dh_systemd/ish is the sole package/program/...
that manages /var/lib/systemd/deb-systemd-helper-masked/ so you can do
the rmdir-if-empty there - you will never remove a directory where any
other package expects that this exists.

In addition to this dh_systemd/ish manage stuff in /etc/systemd,
creating missing directories if neccessary - which is wrong imho since
these directories are also owned by other packages. So the management of
these directories should be left to dpkg by just shipping an empty
directory tree in /etc/systemd with everything that is needed.

You also cannot depend on any package that ships /etc/systemd/system
unless you have no postrm purge activities in that directory. Otherwise
the uncertainty of purge order will remove the other package first.

Andreas