Package: debhelper
Version: 12.1.1
Severity: minor

Dear Maintainer,

I was surprised that a daemon start failure during install did not stop
dpkg from exiting with a successful exit status.  After much digging I
found https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766194#22, which
explains the asymmetry with dh_installinit.  While I'd find an option
for this more appropriate than different behavior, I also feel like the
current state merits some much more prominent documentation at least.
Please consider addig it to the respective compat level as well.

Hi Ferenc

I'm not sure there is an asymmetry with sysvinit, on the contrary.
The "not-fail-on-failures" in dh-systemd (and later dh_installsystemd)
was modelled after sysvinit where SysV init scripts typically have an
"exit 0" at the end of the init script, thus basically ignoring any
error in the init script.

systemd/systemctl internally is more strict, that's why we picked the
"|| true" approach to mimic the old sysvinit behaviour.

Obviously, we could change that to be more picky and abort if a service
fails to start. Question is: do we want that? And if so, why?


Regards,
Michael

Michael Biebl <biebl@debian.org> writes:

I actually took the wording from the linked comment, where Niels wrote:
"Note that debhelper's tooling for init scripts vs. systemd has the
asymmetry that the systemd tooling ignores all failures basically."
Since the maintainer script snippets generated for SysV init scripts
don't ignore the init script failures, the asymmetry is clearly present.

But let's not dwell on this.

Maybe, but that's at the clear discretion of the package maintainer.
(And I don't find it correct practice, but that's not my point now.)

My problem is that this rather mimics badly written init scripts,
without even warning the maintainers (who supposedly want to take
advantage of the more correct/strict systemd behaviour) or letting them
opt out (without wholly ditching the debhelper maintscript snippets).

See above.  But I'm not sure that changing behaviour would be a good
idea, that's why I asked for documentation in this report.  I was bitten
by this in autopkgtest settings, so I'll be adding daemon status checks
to my autopakgtests.  It just took me too long to find out that this
behaviour is intended, because I didn't expect the above asymmetry and
the manual pages don't mention it either.