[Piuparts-devel] Need help with a particular piuparts run
Michael Stapelberg
stapelberg at debian.org
Mon Aug 5 20:10:45 UTC 2013
[+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
More information about the Piuparts-devel
mailing list