[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#766758: apt: does not process pending triggers

On Sat, Nov 15, 2014 at 12:28:07AM +0100, Guillem Jover wrote:
> > I dislike bug-pingpong, but in this case I have to move it back to dpkg
> > as we can't change apt to make upgrades work (at least it was never
> > allowed in the past, so I doubt it is an option now) and its a behaviour
> > change in dpkg, not a apt regression per-se, so dpkg/jessie has to behave
> > as expected by libapt-pkg/wheezy here regardless of how dumb that might
> > be.
> 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…

> > If you agree just clone the bug back to us and I will take care of it
> > from the apt side. You might want to clone it to other dpkg-callers as
> > well as I presume that at least some have the same problem. Otherwise,
> > I am all ears for alternative solutions.
> 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).

> > > 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.

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.

Best regards

David Kalnischkies

P.S.: I will respond to other parts of the mail/thread in other
threads/bugs to keep all reasonably ordered… if that is possible.

Attachment: signature.asc
Description: Digital signature

Reply to: