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

Re: menu handling by cdd-common



On Sat, Apr 17, 2004 at 12:28:42PM +0200, Andreas Tille wrote:
> > In this way no files in ${HOME} are touched except for this script.
> While I wrote the script I wondered how to replace ${HOME}/.menu/cdd-menu
> if necessary?

Do you mean, in the case the code have to be changed?
This issued is probably solved, go on reading:

> Is a "Do not touch this file" comment enough to override the file blindly?
> A backup of this does not suffice because remaining failes in .menu coud
> causes trouble.

I do not follow you, sorry. What's the point?
The transition from old style which touched ~/.menu/ and the current
one?

The fact that a user can modifiy the script?

During last 24h it comes to my mind several ways to use the script, easy
up updating it and so on.

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). 
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.
So a script executing another one is needed.
With a symlink it's really simple to check if user changed anything.

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.

>     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.

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). 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 

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.

cheers,
	c.



Reply to: