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

[Michael Stapelberg]

[+cc Joe Healy, pkg-salt-team]

Hi Andreas,

Sorry for the late response, I have missed your email :(.

Andreas Beckmann <anbe at debian.org> writes:
> 0m22.5s ERROR: FAIL: Package purging left files on system:
>   /etc/systemd/	 not owned
>   /etc/systemd/system/	 not owned
>   /etc/systemd/system/multi-user.target.wants/	 not owned
>   /var/lib/systemd/deb-systemd-helper-enabled/	 not owned
>   /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/	 not owned
>
> Please ship these directories in a package (or more packages, as appropriate)
> s.t. dpkg takes care of creation and removal. Manual rmdir is probably not
> a good idea.
We cannot ship /var/lib/systemd/deb-systemd-helper-enabled/x, because x
is a package-specific value with not only a handful of possibilities but
also oddball cases such as bind9.service.wants/.

pkg-salt noticed that they are still getting piuparts failures with
init-system-helpers 1.7:

http://piuparts.debian.org/sid/fail/salt-master_0.16.2-2.log

AFAICT, if init-system-helpers was fake-essential for piuparts, these
errors would not show up.

In
http://lists.alioth.debian.org/pipermail/piuparts-devel/2013-July/004653.html
you mentioned that this is possible, but pulls in perl, and later you
mentioned that we should not re-implement i-s-h in perl just because of
that (and I’m glad we didn’t, since it was refactored just recently).

I understand the point you are raising, but at the same time, we need a
somewhat pragmatic solution to move forward on this. Having our QA tools
(piuparts in particular) produce bogus reports permanently is not a good
state to be in :).

Can you please make init-system-helpers fake-essential?

-- 
Best regards,
Michael