Re: menu handling by cdd-common
On Sat, 17 Apr 2004, Cosimo Alfarano wrote:
> Do you mean, in the case the code have to be changed?
Yes.
> I do not follow you, sorry. What's the point?
> The transition from old style which touched ~/.menu/ and the current
> one?
No, I mean if we feel the need for changing its code ... but you just
proposed a solution below.
> The fact that a user can modifiy the script?
This is also a point. We have no policy which prevents the user from
changing scripts in his home directory.
> I think the best way is the script in ~/.menu/cdd-menu should call
> scripts in /usr/share/cdd/menu/<something> so there is no problem to
> update the script code except for some cases (user modifies
> ~/.menu/cdd-menu for example).
Sure - this is a very good idea.
> Updating are done directly by dpkg, and ~/.menu/cdd-menu will call the
> 'system' scripts.
> Unfortunatly update-menus doesn't follow symlinks to executable files,
> it considers symlinks as non-executables and doesn't run them.
Ahh, that's sad because exactly this came to mind when I readed your
comment. Should we file a bug report to menu or is this done
intentionally?
> So a script executing another one is needed.
> With a symlink it's really simple to check if user changed anything.
Definitely. But a diff against the old version might do it as well ...
> I'll file a wishlist bug to menu pkg.
>
> > --- menus.orig 2004-04-17 11:08:55.000000000 +0200
> > +++ menus 2004-04-17 11:08:26.000000000 +0200
> [...]
> > but there are several ways how to handle this:
> >
> > 1. Fix linitan (should be done in any case)
>
> It probably can be (temporarely) workarounded by a lintian override
> file, waiting for your fix applied.
Well, I think it is useless effort to work around buggy messages so
I would just ignore them.
> > 2. rename script (I wouldn't like that because the name is fine)
>
> I'm undecided between cdd-update-menus, telling it is part of the 'cdd
> suite', and update-cdd-menus, confortable for Debian-style update-*
> commands. Anyway it's a seconadry issue, and there might be a symlink.
> The second name doesn't raise the problem.
As I said - I like the name and would not change it - just an idea
to work around the lintian stuff.
> The semantic of cdd-update-menus is currently undefined in my mind.
> The current CVS version is quite old (or probaly not, depending on how
> it evolves).
Huh? Old, what is your normal time scale?
> But before commit it again I'd like to understand how CDDs
> need for it.
>
> update-menus operates system-wide if called by root, user-wide if called
> by users.
> Should cdd-update-menus mimic it?
> - as root: get all registered CDDs, all Roles regiserd in each CDD, and
> extract users belonging to those Roles (here became clear why is
> important a good backend, if CDD is complex).
> - as user: simply update ~/.menu/cdd-menu
This seems e good solution to me.
> It's probably useless, if ~/.menu/cdd-menu simply calls a script in
> /usr/share/cdd/ and the second one do all the stuff.
> The only operation to be implemented are
> - install script when user is registered to the first CDD
> - remove script when user is unregistered from the last CDD
> - check in some way if script is still present, for registered users,
> and warn him in some way if it doesn't.
I currently do not have any extension to this list. I decided to start
documenting what you have done. You might have noticed that I checked
in a cdd-update-menus.8 which is more or less a renamed cdd-install-menus.8
which was removed (because cdd-update-menus is much better). If you
would update this man page I would like to start to update the cdd-doc.sgml
to the current state.
Thanks for all your work
Andreas.
Reply to: