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.

Thanks!

Hi!

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

Guillem Jover <guillem@debian.org> writes:

Thanks for the quick reply and considering my request!  I'd definitely
welcome more delegation to dpkg.  However, if and when that happens,
dpkg should perhaps still run hooks every (internal) round to retain
current semantics, so extending the hook interface may be in order
regardless.  I concede that the variable name shouldn't necessarily
mention triggers explicitly; something like DPKG_HOOK_LAST_ROUND=1 would
be more futureproof.  Upon consideration, I suppose it would be best for
the relevant logic to be formally independent of triggers altogether and
instead reflect a new command-line argument apt (or cupt) would then
pass, something like --phase={start,middle,end}.