[Cupt-devel] Bug#766758: apt: does not process pending triggers

[Guillem Jover]

Hi!

On Sat, 2014-11-15 at 11:43:02 +0200, Eugene V. Lyubimkin wrote:
> Did not touch trigger stuff for a while, let's see if I catched up what
> happens here:
> 
> 2014-11-15 00:28, Guillem Jover:
> > [...]
> > Only apt seems to be affected. dselect properly uses “dpkg transactions”
> > and as such queues all configuration in a final «--configure --pending»
> > call. And cupt seems to behave correctly by calling dpkg with
> > «--triggers-only --pending», but Eugene might know for sure.
> 
> Cupt calls '--triggers-only --pending' in the end of run when
> "trigger deferring" (i.e. '--no-triggers') is enabled, which is the
> default (both in wheezy and jessie).

Good then.

> Do I read your explanation [1] correctly that '--triggers-only
> --pending' needs to be invoked (in the end) always, since dpkg may
> choose not to process triggers not just because '--no-triggers' is
> passed, but also because dependencies of a 'triggers-pending' package
> are not satisfied right at that time?

Well, yes and no. If the frontend is smart enough, it might decide to
call «dpkg --triggers-only --pending» only if there are actually
packages pending trigger processing, otherwise it could just skip that
dpkg run. If the frontend is using “dpkg transactions”, then it will
be doing a final «dpkg --configure --pending» which will perform all
configuration and trigger processing, so that'd work too (that's what
dselect is doing for example). Otherwise always calling unconditionally
either --configure or --triggers-only with --pending as a last dpkg run
should do it too, as those calls never fail. But in the end, yeah,
depending on how the frontend interacts with dpkg, the latter might
leave packages pending trigger processing (but not with the workaround
targetting 1.17.22 though).

And w/o wanting to get tiresome with this, take into account that
frontends that use any of the dpkg --force-* options as normal course
of action, will most probably produce intermediate broken states. For
example in #768852 I found that apt was removing libaudit0 before
readahead-fedora had been upgraded, so its dependencies were not
satisfiable when going to process triggers. If apt would have instead
marked libaudit0 for removal using selections, then dpkg would have
been able to remove it in case it needed to, due to conflicts or
similar.

Thanks,
Guillem