Package: menu Version: 2.1.39 Severity: normal Tags: patch The attached patch makes menu support triggers, as implemented in dpkg in (currently) experimental.
When used with an older version of dpkg, menu's current behavior is unchanged, so there's no transition issue. This patch can be applied before a dpkg with triggers reaches unstable. I implemented the standard transition plan as documented in dpkg's triggers.txt. For menu, this consisted of: - Adding a debian/triggers file (which is installed by debhelper), and which registers interest in /usr/share/menu and /usr/lib/menu. This causes dpkg to trigger menu whenever files in those directories are changed. - Modifying update-menus so that, if it detects dpkg is running, it will run dpkg-trigger to manually trigger menu, and then exit. Instead of the nasty fork to background and wait hack, which I have never liked. If dpkg-trigger fails or is not present, it will fall back to the old behavior. - Adding a --real option to update-menus. This can be used to force a real update-menus run even if dpkg is running. It should only be needed to be used by menu internally. - Adding a "triggered" action to the postinst, which runs update-menus --real. This is called by dpkg when menu is triggered. I didn't add trigger support for menu-methods files. It would probably be possible to add that, but since there are not a lot of them, it didn't seem worthwhile at this point. Packages with menu-methods can run update-menus as usual. Note that the code in update-menus to fork to the background could be removed, if you like. Just add a dependency on the version of dpkg to support triggers (once it reaches unstable or testing), and then the code should never need to run and can be removed. Here is an example of how a package installation will look with a triggers-capable dpkg and an unmodified package with a menu item: Unpacking xaos (from .../archives/xaos_3.3-1_i386.deb) ... Selecting previously deselected package xemeraldia. Unpacking xemeraldia (from .../xemeraldia_0.4.1-4_i386.deb) ... Processing triggers for menu ... Setting up xaos (3.3-1) ... Setting up xemeraldia (0.4.1-4) ... Processing triggers for menu ... Note that menu is triggered twice (and update-menus runs twice). It's first triggered by the actual menu file changes, and the second time by the now-redundant update-menus in the postinst. So there's a stage 2 to this transition -- once stable has a dpkg that supports triggers, packages can stop running update-menus in their maintainer scripts. (Unless they have a menu method.) Installation of such a package will look like this: Selecting previously deselected package xemeraldia. (Reading database ... 186450 files and directories currently installed.) Unpacking xemeraldia (from xemeraldia_0.4.1-4_i386.deb) ... Setting up xemeraldia (0.4.1-4) ... Processing triggers for menu ... Performance notes: It's also likely that during a large apt upgrade, dpkg will be run multiple times, and I so update-menus may end up running M times. M will be significantly less than the total number (N) of menu-using packages that are upgraded. I'm guessing it averages to about N/100. IIRC the original fork-to-background hack was an optimisation to avoid N update-menus runs. I think that going back up to N/100 runs is an acceptable tradeoff to be able to get rid of the complexity of update-menus calls in so many postinsts. Additionally, some runtime will be saved by removing postinsts from many packages altogether, and in not making update-menus calls in postinsts. Things will probably balance out fairly well to be about as fast as it is now. Of course, update-menus takes under a second on typical hardware now too. Later on, some simple changes to apt, to make it use --suppress-triggers, can actually bring the number of update-menus runs per apt run back down to 1. (See #473461) -- see shy jo
signature.asc
Description: Digital signature
