Re: menu handling by cdd-common
On Sat, 17 Apr 2004, Cosimo Alfarano wrote:
> With diff there's no way to distinguish between old script install by
> CDD subsystem and script modified by user.
Why not? Prerm could do the comparison and leave a flag anywhere.
> MD5 could achieves it in a better way.
> If the script matches with a MD5 list, it was instaled by system.
Well, when I wrote "diff" I had not the actual program diff in mind
but just *any* test to check for a difference.
> Seriously, I meant that I do not know if the current code for
> cdd-update-menus is still entirely valid/usefull, with the changes I
> Since the main effort of cdd-update-menus is keep updated system's and
> users' menus, and since with the last proposal this effort will be quite
> zeroed, most of the code inside the script might be "old":
> cdd-update-menus uses several loops inside, probably it could be done in
> O(1) at the current state, since there's no more the strong needing to
> keep update ~/.menu/cdd-menu.
Ahh, yes. I like your new solution which goes without the cdd-menu
directory which is not really necessary. So if you are reffering to
the commented part in the script I guess we can drop it. On the
other hand it does not heard if we keep it some further days.
> > 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
> OK, I did not do it waiting for a more stable version of the script.
Sure - that's why I left it more or less as a placeholder to not
forget it ...
> OK. You mean files in doc/common/, don't you?
> I created a small README.CDD to summarize something, but it's only
> for a quick view and not complete. Quite useless.
Not really useless because it can go into the doc directory of the
cdd package. It should reffer to the doc and should suggest the
newly uploaded cdd-doc package.
> /etc/menu-methods/freedesktop-desktop-entry-spec-apps belongs to
> kdelib-bin, probably it's a kde bug, I do not have it installed and
> works fine.
Seems to be the best idea not to have kdelib-bin installed ...