Lately I have been working on the triggers feature of dpkg. I would like to share my plan and what I have done so far. I’ll first explain what triggers are, the current problems, and the work I did to try to improve the situation.
Dpkg triggers are a neat feature of dpkg that package can use to send/receive notifications to/from other installed packages. Those notifications take the form a simple string.
This feature is heavily used to track changes of packaged files in a list of predefined directories, and to update other files based on this. For instance, man-db is watching the directories containing manual pages so that it can update its cache (in
/var/cache/man/). install-info is updating the index of info pages when there have been changes in
/usr/share/info. gnome-menus is updating its own copy of the menu hierarchy (with entries from
/etc/gnome/menus.blacklist blacklisted) every time that a .desktop file is installed/updated/removed.
From a user’s perspective
You see triggers in action very often during upgrades (in fact too often as we’ll see it later):
Preparing to replace zim 0.52-1 (using .../archives/zim_0.52-1_all.deb) ... Unpacking replacement zim ... Processing triggers for shared-mime-info ... Processing triggers for menu ... Processing triggers for desktop-file-utils ... Processing triggers for man-db ... Processing triggers for hicolor-icon-theme ... Processing triggers for python-support ... Processing triggers for gnome-menus ... Setting up zim (0.52-1) ... Processing triggers for python-support ... Processing triggers for menu ...
As you guessed it, those “Processing triggers” lines correspond to the packages which received (one or more) trigger notifications and which are doing the corresponding task.
By default the triggers are processed at the end of the
dpkg --unpack invocation which is often too soon because APT will often call
dpkg --unpack repeatedly during important upgrades. There are some options to ask APT to use dpkg’s
--no-triggers option in order to defer the trigger processing at the end of the APT run. You can put this in
// Trigger deferred DPkg::NoTriggers "true"; PackageManager::Configure "smart"; DPkg::ConfigurePending "true"; DPkg::TriggersPending "true";
I have now asked APT maintainers to use those options by default, I filed bug #626599 to track this. At the same time I fixed bug #526774 reported by APT maintainers. This bug forced them to put a work-around in APT which resulted in running triggers sooner than expected.
(And while writing this article I filed bug #628564 and #628574 because it was clearly not normal that the menu triggers was executed twice for the installation of a single package)
From a packager’s perspective
The implementation of triggers has several consequences on the status that packages can have.
Let’s assume that the package A installs a file in a directory that is watched by package B (and that B is currently in the “installed” state). When A is unpacked, dpkg adds B to its “Triggers-Awaited” field and lists the activated trigger in B’s “Triggers-Pending” field. Package A is in “unpacked” state, but B has been changed to “triggers-pending”.
When A is configured, instead of going to the “installed” state, it will go to the “triggers-awaited” state. In that state the package is assumed to NOT fulfill dependencies. However, B—which is still in “triggers-pending” state—does fulfill dependencies.
A and B will switch to “installed” at the same time when the trigger has been processed.
The fact that the triggers-awaited status does not fulfill dependencies means that some common triggers like man-db have to be processed regularly just to be able to ensure dependencies are satisfied before running the postinst of other installed packages.
But a package which ships a manual page can certainly be considered as configured when its postinst has been run even if man-db has not yet updated its cache to know about the new/updated manual page.
When you activate a trigger with the dpkg-trigger command you have an option
--no-await to avoid awaiting the trigger processing (and thus to go directly to installed state after the postinst has been run). But with file triggers or activate trigger directives, you do not have this option.
My proposal to improve the situation
This is the problem that I tried to solve during my last vacation. But before changing the inner working of triggers, I wrote a non-regression test suite for that feature (commit here) so I could hack with some confidence that I did not break everything.
The result has been presented on the debian-dpkg mailling list: see the discussion here. I added new directives that can be used in triggers files that work exactly like the current triggers except that they do not put triggering packages in trigger-awaited status.
I believe the code to be mostly ready, but in its current form the patch brings zero benefits until all packages have been converted to use the trigger variants that do not require awaiting trigger processing (and the change requires a pre-dependency on dpkg to ensure we have the required dpkg that understands the new kind of trigger directives).
Thus I wonder if I should not change the default semantic of triggers. The packages which really provide crucial functionality to awaiting packages through triggers would then have to be updated to switch to the new directives.
If you’re a packager using triggers, you can thus help me by answering this question: do you know some triggers where it’s important that the awaiting packages are not considered as configured before the trigger processing? In most of the cases I checked, it’s important for the triggered package rather than for the triggering package.
In truth, a package in triggers-awaited status is usually in a good enough shape to be able to satisfy dependencies (i.e. requirements that other packages can have), but it would still be worth to record the fact that it’s not entirely configured yet because it might be true from the user’s point of view: for example if the menu trigger has not yet been processed, the software might not yet be visible in the application menu.
If you appreciate this kind of groundwork that benefits to the whole Debian ecosystem, please consider supporting my work. Click here and give it a look, there are many ways to contribute and to make a difference for me.
Cody Somerville says
You’re doing some incredible work. This work will provide significant performance improvements (especially on ARM where some of these triggers are quite expensive) to package installation in certain scenarios. Keep up the great work!
Raphaël Hertzog says
Thank you for the kind words!
I have noticed in recent versions of Ubuntu, installing applications takes so long. The system will hang on these triggers.
You suggested code to include the following in /etc/apt/apt.conf.d/triggers:
// Trigger deferred
Since neither that dir or file existed, I put the code in
Is that what you intended? I’ll run it this way for a while to see.
Will advise any unusual results.
Raphaël Hertzog says
Richard, I was suggesting to create this file… but the result is the same in the end.
And it seems to work as intended on squeeze.
I removed OOo3.3.2 and LibO3.4 with apt-get, (since they were installed directly with dpkg,
then reinstalled them both, one by one, with dpkg -i *.deb
The triggers generally seemed to come at the end of the install.
Both completed with no errors.
Regards and thanks.