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 -- 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/20141211075023.ga10...@gaara.hadrons.org
