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 -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141115172416.ga...@gaara.hadrons.org