Hi! On Sun, 2024-10-13 at 21:35:05 -0400, Aaron M. Ucko wrote: > Package: dpkg > Version: 1.22.11 > Severity: normal > X-Debbugs-Cc: debian-security-supp...@packages.debian.org
> As dpkg's man page notes, complex apt runs can yield multiple > invocations of dpkg and hence also of dpkg-level hooks. As (at > minimum) I and the reporters of #775503 and #931344 have found, this > arrangement can interact somewhat poorly with debian-security-support, > which then prompts in the middle of long upgrades (or buries short > reports when using the readline debconf frontend); I'm copying its > maintainers accordingly. > > I see that apt arranges to defer triggers for efficiency on that > front. Having --no-triggers outright disable post-invoke hooks could > plausibly break some setups, but perhaps it could result in invoking > them with some special environment setting so that they could then > cleanly bail unless they truly needed to run quite so promptly. > > Ideally, pre-invoke hooks should analogously be able to identify an > apt run's first dpkg invocation. However, that may be easier said > than done, and I'm not sure it's as much of a concern in practice. Hmm, it seems to me you are asking for a feature so that the user of the dpkg hooks can infer how an upper layer tool driving dpkg is operating it. This feels like the wrong approach to design such an interface as it ties it with how currently apt operates, where ideally in the future apt would be able to perform a single or a couple calls and delegate everything to dpkg itself, which this proposed usage might then prevent. Instead I think that, what would be better is to switch the user from dpkg hooks to apt hooks? Thanks, Guillem
