[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 :),

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.


Reply to: