On Mon, Mar 09, 2009 at 01:21:19PM -0400, Joey Hess wrote:
> Bill Allombert wrote:
> > Then it is a bug in debhelper. It should still call update-menus in the
> > postinst, (or triggers it using dpkg-trigger).
> >
> > The problem is that menu only display menu entries for configured
> > packages, because unconfigured or half-configured packages generally
> > do not work. Without an explicit trigger in the postinst, dpkg run
> > the trigger before the package is configured and then update-menus
> > ignores it. This is related to bug #473461 which cause update-menus
> > to be run twice in some case which is a regression from Etch.
>
> It'd be a real shame if it turns out we cannot use triggers to eliminate
> all the update-menus calls and eventually get rid of the ugly
> backgrounding code in update-menus.
Well, that is not so bad, because you can replace
# Automatically added by dh_installmenu
if [ "$1" = "configure" ] && [ -x "`which update-menus 2>/dev/null`" ];
then
update-menus
fi
by something like
dpkg-trigger /usr/share/menu
> I wonder how useful it is for menu to test for
> unconfigured/half-configured packages at all.
This is mostly useful for packages that are broken and won't get
fixed until an admin manually fix the system.
But anyway, this is a correctness issue, and this is not specific to
menu, simply menu has more experience with trigger than anything else.
dpkg should provide a way to run triggers after packages are configured.
I suggest you reinstate the explicit trigger and that we ask for
dpkg to provide a solution to that issue.
> * That test does not cover unconfigured/half-configured
> dependencies, which could also potentially break a menu item.
Yes, but only if there are circular dependencies( which have their own
share of issue). Without circular dependencies, if a package is
configured, then all its dependency must be configured.
> * If a package is temporarily de-configured in the middle of an apt run
> and then re-configured, update-menus will not be run in time to
> notice this happened, and the menu item will remain available
> throughout.
> * There's a window in package removal where all the files are gone,
> but the postrm has not run, when the menu items are certianly broken
> but still vidible. This is surely a more common case than any of
> the others, and yet update-menus doesn't handle it. (Triggers may
> have narrowed this window, I haven't checked.)
Not sure about those two, but menu suffers from various race condition
by the mere fact that most window manager only read the menu file
at startup. However triggers does not affect that.
> * No such checks are done for desktop files, which are of course, where
> most naive users will really get their menus from..
I do not take any part in the numerous defect of the XDG draft and its
various implementations.
> So I guess it's up to you if you want to leave this test in. If you do,
> I can either revert the debhelper change or add code to manually trigger
> menu in the postinst. I'm not sure if explicitly triggering menu will
> result in update-menus running less often or not, so am inclined not to
> bother trying to do that.
At least this would allow to remove the code in update-menus that
trigger menu (and the --trigger option).
// Check if the dpkg lock is taken
if (check_dpkglock())
{
if (! config.trigger)
{
// Try to use dpkg-trigger to trigger the menu update later.
if (system("dpkg-trigger --by-package=menu /usr/share/menu >/dev/null
2>&1") == 0)
{
// Success, so no need to do anything now.
exit(0);
}
}
Cheers,
--
Bill. <ballo...@debian.org>
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
