Guillem Jover <guil...@debian.org> writes:
> 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 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}.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
