XPost: linux.debian.maint.dpkg
Hi!
On Mon, 2025-07-21 at 11:41:51 +0200, Guillem Jover wrote:
On Sun, 2025-07-20 at 09:45:37 +0200, Niels Thykier wrote:
I have cloned and reassign a bug for `dpkg` to make it announce
postinst abort-upgrade, so this becomes less of a problem in the
future. @Guillem: Concretely, the issue is we were only informed
about `preinst` failing but in reality `preinst` failed and then
`postinst abort-upgrade` failed as well. The output we saw from the maintscript itself was from `postinst` (the preinst failure was
silent, so the postinst failure was the only output we had to go
from).
I took a quick look at the involved code before departing from DebConf yesterday, and came up with a potential fix. But afterwards when trying
to create a minimal test case for the functional test suite, I'm actually getting the expected stacked error messages, such as:
,---
(Reading database ... 1 file or directory currently installed.)
Preparing to unpack pkg-stacked-error-1.deb ...
dpkg: error processing archive pkg-stacked-error-1.deb (--unpack):
new pkg-stacked-error package pre-installation script subprocess returned error exit status 1
dpkg: error while cleaning up:
installed pkg-stacked-error package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
pkg-stacked-error-1.deb
`---
So I think I'm probably missing some step or my test case is not doing
the same as what is going on in the report. I'll try to run the provided mmdebstrap rune with dpkg set to include maintscript debugging logging,
to try to see what's exactly going on later today.
- A new bug (important) about the preinst being silent on aborting
the upgrade. It would have helped a lot of the preinst had explicitly
echo'ed "Aborting upgrade as requested" (or something along those
lines), as it would have been easier to identify the root cause
here
Indeed.
I tried to reproduce this problem with the original mmdebstrap recipe,
by creating a config file for dpkg with "debug 3", and there it seems
to confirm my observation that the preinst is the only thing failing
here, and that otherwise dpkg should have printed the stacked errors
for all involved failing maintscripts.
Rechecking the original log (and confirming by checking the DEBIAN/
contents from both bacula-common deb versions from bookworm and
trixie), the systemd-tmpfiles call is protected by "|| true" so
whether it fails or not, the script itself just succeeded (from dpkg's
PoV).
I guess the problem is that the original preinst fails silently, and
the subsequent failure in postinst when calling systemd-tmpfiles (which
causes no maintscript failure) is the only visible output. Although in
this case given that it was printed after the dpkg error message, it
could be understood as happening later on in some other place. But I
understand this might not always be clear/obvious.
Given that the preinst failure is not going to be recoverable with the subsequent maintscript calls (so the package unpack will fail), and
this should not be the usual sequence of invocations, I guess the only
way to improve the current output would be to print an explicit notice
whenever a maintscript is being called for "abort-*" cases, similar to
what we already have for the "failed-*" cases. I think the increased
verbosity would then be fine as in those execution flows the package
will always end up in an action failure (where with "failed-*" the
action can actually even recover from it).
Thanks,
Guillem
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)