Bug#769609: apt: does not process pending triggers
Hi!
On Sun, 2014-11-23 at 18:39:05 +0100, David Kalnischkies wrote:
> On Sat, Nov 15, 2014 at 12:28:07AM +0100, Guillem Jover wrote:
> > Sure, although the current apt behavior goes against the written
> > triggers spec, where apt/aptitude even have their own section. :)
>
> I don't want to be seen as picky, but it doesn't. Especially the
> mentioned section isn't violated. We know these states and we call
> configure for them if we see them, but the next line says we usually
> will not see them. What you did now is changing the "usual" in this
> sentence to "in the way you are using it, it will be close to always".
>
> Triggers are from our viewpoint an implementation detail of dpkg (which
> is also what the spec suggests), which leaks into our domain more and
> more for "good" reasons, but at the same time its bad as we can't really
> deal with them as there is no way to predict what will happen…
I think they are leaking into your domain mainly because apt has
always tried to micromanage dpkg too much. I'll reply to that in more
depth in the other mail.
> > 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.
> >
> > If you know of other frontends, I'd be interested to know.
>
> Well, I don't know, but I would guess that at least the various
> (cross-)bootstrappers need to be checked. smartpm (although, it might be
> better to just remove it). d-i maybe, but I guess it doesn't use dpkg
> directly (and/or later states with apt will "fix" that up). codesearch
> might help if you can come up with a good search pattern (I couldn't).
Ah thanks for the list. I don't think bootstrappers are affected, they
deal with much earlier state. I'll be checking smartpm. d-i should be
using udpkg+anna, and yeah later stuff just uses dpkg+apt.
> > > > So apt needs to either pass man-db to the --configure call, or just
> > > > do a final --triggers-only/--configure --pending call. A trivial fix
> > > > would be to change the default value for DPkg::TriggersPending to
> > > > true.
>
> I just realized that we also have a dpkg::ConfigurePending option
> causing apt to run a "dpkg --configure --pending" after all other dpkg
> calls, so I will opt for this one as it is more future proof and does
> what we need just as well.
Ah, yeah, sorry I didn't mention that explicitly, I though it was
obvious from the «--configure --pending» reference there. And yeah
using that sounds good, and possibly better actually.
> Reasoning: I just tried the following sequence:
> dpkg -i trigdepends-interest_1.0_all.deb triggerable-interest_1.0_all.deb
> # ^ dependency ^ interest /usr/share/doc
> dpkg --unpack trigdepends-interest_1.0_all.deb
> dpkg --unpack trigstuff_1.0_all.deb
> dpkg --configure trigstuff
> # ^ trigstuff is iW as dependencies of trigger aren't statisfied
> dpkg --triggers-only --pending
> My expectation I expressed in the previous mail was that the last
> command here would fail as a pending trigger can't be run. It doesn't,
> so my biggest concern with dpkg::TriggersPending isn't really existing,
> but I still think that running it all the time isn't needed if we can
> just do the more general ConfigurePending once.
That should properly fail now with 1.17.22, so yeah always using
«--confiure --pending» is the more correct and general option anyway.
Thanks,
Guillem
Reply to: