Bug#473467: the patch
Hello Joey, Can you have a look at bug #484167 about triggers and menu ? It seems dpkg is running the menu trigger before the the triggering package is configured. 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: the patch
Bill Allombert wrote: Hello Joey, Can you have a look at bug #484167 about triggers and menu ? It seems dpkg is running the menu trigger before the the triggering package is configured. Right, dpkg can run the trigger at any time it choses after unpacking the package, and currently it seems to do so before configuration, though I'm not sure why that choice was made. I hadn't considered that this could break some executable menu files that depend on their package being configured when I made menu use triggers. However, thinking about it some more, packages like cdd-common were already broken before menu became triggerized. The breakage just wasn't as likely to show up, but could occur: dpkg --unpack a-game.deb cdd-common.deb dpkg --configure --pending IIRC dpkg --configure --pending configures in alphabetical order. So a-game would be confgured first, when cdd-common was unpacked but not yet configured. If a-game uses menu, then update-menus runs, running cdd-common's menu program, which would fail the same as it does with triggers. I think you could probably also cause the same problem by just installing both packages with dpkg at once, since it would unpack both and then configure a-game first. -- see shy jo signature.asc Description: Digital signature
Bug#473467: the patch
On Sun, Jun 08, 2008 at 01:26:57PM -0400, Joey Hess wrote: Bill Allombert wrote: Hello Joey, Can you have a look at bug #484167 about triggers and menu ? It seems dpkg is running the menu trigger before the the triggering package is configured. Right, dpkg can run the trigger at any time it choses after unpacking the package, and currently it seems to do so before configuration, though I'm not sure why that choice was made. I hadn't considered that this could break some executable menu files that depend on their package being configured when I made menu use triggers. What do you suggest ? Would checking for the config file existence be enough ? However, thinking about it some more, packages like cdd-common were already broken before menu became triggerized. The breakage just wasn't as likely to show up, but could occur: dpkg --unpack a-game.deb cdd-common.deb dpkg --configure --pending IIRC dpkg --configure --pending configures in alphabetical order. So a-game would be confgured first, when cdd-common was unpacked but not yet configured. If a-game uses menu, then update-menus runs, running cdd-common's menu program, which would fail the same as it does with triggers. I am not saying the old system is fullproof, but update-menus was never run before the dpkg lock was released which only happened after 'dpkg --configure --pending' returned, at which point both a-game and cdd-common would be configured. 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: the patch
Bill Allombert wrote: What do you suggest ? Would checking for the config file existence be enough ? I think it should also take care to manually call update-menus in its postinst, to make sure its menu program runs after it's configured. However, thinking about it some more, packages like cdd-common were already broken before menu became triggerized. The breakage just wasn't as likely to show up, but could occur: dpkg --unpack a-game.deb cdd-common.deb dpkg --configure --pending IIRC dpkg --configure --pending configures in alphabetical order. So a-game would be confgured first, when cdd-common was unpacked but not yet configured. If a-game uses menu, then update-menus runs, running cdd-common's menu program, which would fail the same as it does with triggers. I am not saying the old system is fullproof, but update-menus was never run before the dpkg lock was released which only happened after 'dpkg --configure --pending' returned, at which point both a-game and cdd-common would be configured. Ah, you're right. The scenario where the problem could occur before was thus much less likely: dpkg --unpack cdd-common.deb dpkg -i a-game.deb -- see shy jo signature.asc Description: Digital signature
Bug#473467: the patch
On Sun, Mar 30, 2008 at 04:11:01PM -0400, Joey Hess wrote:
diff --new-file -ur old/menu-2.1.38/update-menus/update-menus.cc
menu-2.1.39/update-menus/update-menus.cc
--- old/menu-2.1.38/update-menus/update-menus.cc 2008-03-03
15:13:45.0 -0500
+++ menu-2.1.39/update-menus/update-menus.cc 2008-03-30 14:46:53.0
-0400
@@ -802,14 +804,32 @@
// Check if the dpkg lock is taken
- if (check_dpkglock()) {
+ if (check_dpkglock())
+ {
+if (! config.real)
+{
+ // Try to use dpkg-trigger to trigger the menu update later.
+ if (system(dpkg-trigger /usr/share/menu /dev/null 21) == 0)
+ {
+// Success, so no need to do anything now.
+exit(0);
+ }
+}
Hello Joey,
I wonder if this is correct.
What happen if the user run update-menus manually while the dpkg lock is
held ? 'dpkg-trigger /usr/share/menu' will fail because
DPKG_MAINTSCRIPT_PACKAGE is not set.
Maybe we should do
dpkg-trigger --by-package=menu /usr/share/menu
to cover this case.
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: the patch
Bill Allombert wrote:
On Sun, Mar 30, 2008 at 04:11:01PM -0400, Joey Hess wrote:
diff --new-file -ur old/menu-2.1.38/update-menus/update-menus.cc
menu-2.1.39/update-menus/update-menus.cc
--- old/menu-2.1.38/update-menus/update-menus.cc2008-03-03
15:13:45.0 -0500
+++ menu-2.1.39/update-menus/update-menus.cc2008-03-30
14:46:53.0 -0400
@@ -802,14 +804,32 @@
// Check if the dpkg lock is taken
- if (check_dpkglock()) {
+ if (check_dpkglock())
+ {
+if (! config.real)
+{
+ // Try to use dpkg-trigger to trigger the menu update later.
+ if (system(dpkg-trigger /usr/share/menu /dev/null 21) == 0)
+ {
+// Success, so no need to do anything now.
+exit(0);
+ }
+}
Hello Joey,
I wonder if this is correct.
What happen if the user run update-menus manually while the dpkg lock is
held ? 'dpkg-trigger /usr/share/menu' will fail because
DPKG_MAINTSCRIPT_PACKAGE is not set.
Maybe we should do
dpkg-trigger --by-package=menu /usr/share/menu
to cover this case.
That sounds right.
--
see shy jo
signature.asc
Description: Digital signature
Bug#473467: the patch
attached -- see shy jo diff --new-file -ur old/menu-2.1.38/debian/changelog menu-2.1.39/debian/changelog --- old/menu-2.1.38/debian/changelog 2008-03-05 10:59:58.0 -0500 +++ menu-2.1.39/debian/changelog 2008-03-30 14:31:00.0 -0400 @@ -1,3 +1,9 @@ +menu (2.1.39) UNRELEASED; urgency=low + + * Add trigger support. + + -- Joey Hess [EMAIL PROTECTED] Sun, 30 Mar 2008 14:30:56 -0400 + menu (2.1.38) unstable; urgency=low * The little zebra release. diff --new-file -ur old/menu-2.1.38/debian/postinst menu-2.1.39/debian/postinst --- old/menu-2.1.38/debian/postinst 2005-06-28 08:27:32.0 -0400 +++ menu-2.1.39/debian/postinst 2008-03-30 14:49:11.0 -0400 @@ -13,13 +13,22 @@ # kill -KILL `pidof update-menus` 2 /dev/null || true #fi -chmod a+x /usr/bin/update-menus -update-menus +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 +;; +*) + chmod a+x /usr/bin/update-menus + update-menus -install-info --quiet \ ---menuentry=Debian menu \ ---section Information Information: \ ---description=The Debian menu system \ -/usr/share/info/menu.info + install-info --quiet \ + --menuentry=Debian menu \ + --section Information Information: \ + --description=The Debian menu system \ + /usr/share/info/menu.info +;; +esac #DEBHELPER# diff --new-file -ur old/menu-2.1.38/debian/triggers menu-2.1.39/debian/triggers --- old/menu-2.1.38/debian/triggers 1969-12-31 19:00:00.0 -0500 +++ menu-2.1.39/debian/triggers 2008-03-30 14:30:52.0 -0400 @@ -0,0 +1,2 @@ +interest /usr/share/menu +interest /usr/lib/menu diff --new-file -ur old/menu-2.1.38/doc/README.changes menu-2.1.39/doc/README.changes --- old/menu-2.1.38/doc/README.changes 2002-05-18 10:49:54.0 -0400 +++ menu-2.1.39/doc/README.changes 2008-03-30 15:02:03.0 -0400 @@ -8,7 +8,8 @@ update-menus *forks to background, waits for dpkg to finish (to get a _correct_ - package listing). + package listing). (This is now only done with dpkgs that don't support + triggers.) *allows new menuentry format: needs=text command=/usr/bin/vi section=Apps/Editors title=Vi \ diff --new-file -ur old/menu-2.1.38/doc/menu.sgml menu-2.1.39/doc/menu.sgml --- old/menu-2.1.38/doc/menu.sgml 2008-02-27 09:15:09.0 -0500 +++ menu-2.1.39/doc/menu.sgml 2008-03-30 15:28:11.0 -0400 @@ -145,6 +145,10 @@ p When a package that wants to add something to the menu tree gets installed, it will run prgn/update-menus/ in its file/postinst/ script. +Or, if the package is used with a trigger-enabled version of dpkg, it can +omit that, since the menu package registers interest in all files in +file/usr/lib/menu/file and file/usr/share/menu/file, and will be +automatically triggered by dpkg when those files change. Update-menus then reads in all menu files in file/etc/menu//file, file/usr/lib/menu/file, file/usr/share/menu/file and file/usr/share/menu/default/file, and stores the menu entries of all @@ -814,6 +818,11 @@ (that is, the same line in postinst and in postrm). p +Note that this is not needed if the package will only be used with dpkg +1.4.18 or better and menu 2.1.39 or better. The newer versions use triggers +to automatically run update-menus. +p + chaptWhat packages with menu managers should do p @@ -1006,13 +1015,17 @@ On startup, update-menus checks the file file/var/run/update-menus.pid/ and the pid in it. If there's an prgn/update-menus/ process with that pid it kills it. -If file/var/lib/dpkg/lock/ exists, it forks to background and -returns control to dpkg. The background process checks the +If file/var/lib/dpkg/lock/ exists, it checks to see if dpkg supports +triggers. If so, it uses dpkg-trigger to trigger a real update-menus run later. +Otherwise, it forks to background and returns control to dpkg. The background +process checks the file/var/lib/dpkg/lock/ file approx. every second until the file's gone. p -After that, prgn/update-menus/ reads the menu-entry files in +Once it's decided to run, whether in the background after dpkg exits, or in +the foreground when used with a trigger-capable dpkg, +prgn/update-menus/ reads the menu-entry files in the following directories: file/etc/menu/, file/usr/lib/menu/, file/usr/share/menu/, file/usr/share/menu/default/. (if a user runs prgn/update-menus/, it will add file~/.menu/ to the Binary files old/menu-2.1.38/update-menus/.update-menus.cc.swp and menu-2.1.39/update-menus/.update-menus.cc.swp differ diff --new-file -ur old/menu-2.1.38/update-menus/update-menus.cc menu-2.1.39/update-menus/update-menus.cc --- old/menu-2.1.38/update-menus/update-menus.cc 2008-03-03 15:13:45.0 -0500 +++ menu-2.1.39/update-menus/update-menus.cc 2008-03-30 14:46:53.0 -0400 @@ -789,6 +789,8 @@ } /** Check
