Re: Bug in cdd-update-menus
On Tue, Apr 20, 2004 at 02:35:14PM +0200, Andreas Tille wrote:
> > update-menus --nodefaultdirs --menufiledir ~/.menu/
> > should update only menus in ~/.menu, try -v for verbose output.
> > I cannot test it now, but it quicker then the simply "update-menus".
> Hopefully this works nicely with all WMs. BTW, the Gnome menu seems
> to remain untouched by update-menus (I guess KDE works - why should it
> have trown errors else).
gnome-panel method is provided in /etc/menu-methods/gnome-panel
which updates ~/.gnome/apps/ tree, but I'm not so skilled in gnome
internals :)
Tried to ask some days ago on #debian-devel for a quick enlightenment,
without results.
> I'm unsure whether we should provide such a "do-the-dirty-work-script"
> in /usr/share/cdd/cdd-update-user-menus or whether I should put it
> into med-common. The rationale for putting this into cdd-common is:
>
> - I'm using the post{inst,rm} scripts from cdd-dev templates and
> thus it should know the scripts which are called from here.
> - Other CDDs might like to use this trick for the time beeing
> as well. (Any comments here????)
the one proposed was the quickest suitable solution, not the best :),
anyway:
If cdd-dev's template creates post* scripts, it can be added directly as
code portion, instead of executing a script in /usr/share/cdd.
Append it to templates/postinst, using #CDD# instead of med.
Why I prefer an inline solution in post* script, rather then a script:
It may append that a script, particularly a temporary one, disappers in
a future version of cdd-{common,dev}, but some pkgs (build with an old
version of cdd-dev) with post* script trusting on it and not updated may
be installed, failing in postinstallation (no more script there).
We should try to provide compatibility along versions too, and it's a
good chance to think how the things can break.
With the said loops 'inline', the script will works as long as the
interface to cdd-common script will remain the same, and a rebuild of
package will recreate updated post* scripts.
In the other way, a strict dependancies on a specific cdd-common version
should be used by CDD, with some problem on installation and in being
allowed in Testing.
Play with flying script could be a PITA ;)
BTW: if cdd-dev uses script/functions in cdd-common, it has to depend on
it, there is a reason I cannot see why it doesn't?
> On the other hand /etc/cdd/med/med.conf could define a "postinst-helper"
> script which could be run from a general post{inst,rm} script and might
> be void for other CDDs.
I'd prefer <CDD>.conf defines only variables, without running any
script/code, related only to cdd-common issues.
A /etc/cdd-dev/#CDD#.conf could be used instead
(/etc/cdd/#CDD#-dev.conf, but it leads to confusion if there are two
CDD, one named X and the other X-dev).
Or postinst-helper could be added to CDD's post* scripts by some
parameters (of conffile) in cdd-install-helper, using
#POSTINSTHELPER# variable in tamplates, that expands to void if CDD
doesn't define anything, or to the script to be executed, if defined.
cosimo.
Reply to: