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.
signature.asc
Description: Digital signature