Control: severity -1 serious Control: clone -1 -2 Control: retitle -1 dpkg: Needs to workaround apt not processing pending triggers Control: affects -1 Control: reassign -2 apt
[ CCed cupt maintainers, please see below. ] On Sun, 2014-11-02 at 15:26:06 +0100, David Kalnischkies wrote: > On Wed, Oct 29, 2014 at 05:41:25PM +0100, Guillem Jover wrote: > > This should probably be considered an RC bug, but I'll let the apt > > maintainers deal with that. I've bumped it to serious now for both, if you disagree, please lower the one on your end. > Every libapt-based tooling has this problem and will all be fixed by the > same fix, BUT this bug effects stable upgrades as apt (/aptitude/ > synaptics/…) will upgrade dpkg pretty early in the upgrade process and > the new dpkg (with its behaviour change) will deal with the rest of the > upgrade and so everyone will have unprocessed triggers. This is > unacceptable IMHO and nothing we can paper over with a release notes > entry. Right. > 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 would suggest that "--configure foo" is extended to implicitly run > all pending triggers by default for jessie (at least those which can be > run as their dependencies are satisfied). We (as in apt) will change > apt/jessie to run "dpkg --triggers-only --pending" after the last dpkg > invocation and you can change dpkg/jessie+1 to behave like it does now. > (assuming the release team agrees to this plan) Now that I've been able to track down and fix all remaining triggers fallout in dpkg, I've implemented something like this locally. When using «dpkg --configure pkgname...» w/o --no-triggers, dpkg will populate the deferred triggers queue with any package pending trigger processing. This queue is processed at the end of the dpkg run, but is opportunistic, and will not fail if the dependencies for those packages cannot be satisfied, which *might* sill leave packages in not fully installed states, but if that happens then that's probably either a packaging or apt bug anyway. It seems to me this might not conform to the triggers spec, with a very strict reading of it. But given that dpkg has not honored dependencies for them up to very recently, it does not make sense to try to be holier than the pope here. > Not the most efficient solution as dpkg and apt in jessie will both waste > some time doing stuff they don't have to just for the sake of upgrades, > but compared to the time they take to do their actual work, its > negligible and doing funky stuff to detect an upgrade in progress > are probably going to explode… Yeah, it's just annoying code-wise, work-wise it's just a matter of scanning all installed packages, which should be quick. The trigger processing would have been performed on a previous run before dpkg was checking dependency satisfiability anyway, so no visible additional work due to that either, maybe even less work. > 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. > > 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. > > The option exists in apt/wheezy already, but it runs --triggers-only after > EVERY explicit --configure call¹, which can be quiet frequent as e.g. > every (pseudo-)essential package is configured on its own. I had it > implemented to circumvent #526774. Now it isn't needed anymore… > (well, it never was as the whole option group was never the default. > I hope to have some time after jessie release to look into this as its > kinda embarrassing that I wanted to do it for 5 years now…) > Anyway, we can't enable this option retroactively even if we wanted to… Sure, but enabling it for Jessie would allow for this to be fixed properly during Stretch, and for the dpkg workaround to possibly be removed immediately in dpkg 1.18.x. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
