Bug#473467: support for triggers (stage 1)
Hello Joey, On Sun, Mar 30, 2008 at 04:06:15PM -0400, Joey Hess wrote: - 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. Where is that documented ? deb-triggers(5) does not actually say something about directories. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473467: support for triggers (stage 1)
Bill Allombert wrote: Hello Joey, On Sun, Mar 30, 2008 at 04:06:15PM -0400, Joey Hess wrote: - 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. Where is that documented ? deb-triggers(5) does not actually say something about directories. From triggers.txt: File triggers have names of the form /path/to/directory/or/file and are activated when the specified filesystem object, or any object under the specified subdirectory -- see shy jo signature.asc Description: Digital signature
Bug#473467: support for triggers (stage 1)
Bill Allombert wrote: 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. What would be the cost to add /etc/menu-methods to debian/triggers ? Do conffiles release triggers ? There are about 55 menu-methods. The issue is that menu-methods files are currently shipped non-executable and made executable to enable them in the postinst, followed by an update-menus run. If update-menus is triggered before the postinst (which can happen with a trigger), it would still need to be run manually once the postinst chmods the menu-methods file. 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: Personnaly, I would prefer to delay the stage 2 after the release of lenny. This way partial upgrades are not broken (i.e. menu version is kept at etch, but some packages are upgraded to lenny). Also, there are pending menu transitions I like to finish before staring a new one. Yes, as I said, stage 2 needs to happen after stable has a version of dpkg (and menu) that supports triggers. -- see shy jo signature.asc Description: Digital signature
Bug#473467: support for triggers (stage 1)
On Sun, Mar 30, 2008 at 04:06:15PM -0400, Joey Hess wrote: The attached patch makes menu support triggers, as implemented in dpkg in (currently) experimental. Hello Joey, Thanks a lot for your patch and analysis. My comments: - 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. Given the above, I have renamed it to --trigger and did not documented it yet to avoid breaking translations. - 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. What would be the cost to add /etc/menu-methods to debian/triggers ? Do conffiles release triggers ? There are about 55 menu-methods. 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: Personnaly, I would prefer to delay the stage 2 after the release of lenny. This way partial upgrades are not broken (i.e. menu version is kept at etch, but some packages are upgraded to lenny). Also, there are pending menu transitions I like to finish before staring a new one. 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) This would be good, because the 'two second' sleep prevented most of those spurious update-menus runs. update-menus can be slow if the menu-methods are slow (e.g fvwm-crystal) and some people (me...) have all the 55 menu-methods installed. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473467: support for triggers (stage 1)
Hi! +case $1 in +triggered) + # This is triggered by any installation of a menu file and by + # any call to update-menus made in a package maintainer script. + update-menus --real +;; +*) Joey, I was wondering if there should be an exit 0 after processing the trigger. There is a #DEBHELPER# stanza at the end of postinst, and not all postinst rules, that are generated by debhelper contain a if [ $1 = configure ... ] check. This means, such snippets would be run when the trigger is processed. Admittedly, currently the only shell code that is added by debhelper is the one by dh_installinfo (which is guarded by a $1 = configure check). Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#473467: support for triggers (stage 1)
Michael Biebl wrote: Hi! +case $1 in +triggered) + # This is triggered by any installation of a menu file and by + # any call to update-menus made in a package maintainer script. + update-menus --real +;; +*) Joey, I was wondering if there should be an exit 0 after processing the trigger. Good catch, there should be. In this case, all the debhelper-added fragments test for $1 = configure and do nothing, but in general, you can't know that. -- see shy jo signature.asc Description: Digital signature
Bug#473467: support for triggers (stage 1)
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
