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

[Michael Stapelberg]

Hi Andreas,

Andreas Beckmann <anbe at debian.org> writes:
>> We currently do have a few remaining packages which ship files in
>> /etc/systemd. Those should be fixed.
>
> Is there a lintian check for this?
Not yet, I think.

>> We could ship /etc/systemd/system in i-s-h, but would that help?
>
> That would solve the piuparts issue.
> i-s-h should ship all directories below /etc/systemd that it might need
> to use at some point *and* that are also shipped in the systemd package
> (or any "buggy" package) to make it clear: "this directory is managed by
> dpkg" (while everything is /var/lib/systemd is solely managed by i-s-h).
i-s-h cannot know what some package might want to use at some point
underneath /etc/systemd.

deb-systemd-helper (which is the part of i-s-h we talk about here) is
just a script to create the symlinks necessary to enable a systemd unit
file.

systemd units live in
e.g. /lib/systemd/system/apache2.service. Depending on which target(s)
the unit file belongs to, it will be activated by creating e.g.
/etc/systemd/system/multi-user.target.wants/apache2.service.

Now you could argue that we should just hard-code the most common
targets (they are analogous to runlevels in sysvinit), but that doesn’t
help: units can also be installed for other unit files. We have that
situation in bind9, where bind9-resolvconf.service is a service that,
when enabled, is linked from
/etc/systemd/system/bind9.service.wants/bind9-resolvconf.service so that
it will be started whenever bind9 is started.

I hope I made it clear why the hierarchy underneath /etc/systemd/ is too
dynamic to be shipped in any single package.

What options do we have to fix this piuparts problem?

Thanks.

-- 
Best regards,
Michael