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

Menu package, user updates, include (Was: KDE/SEUL)



(Moved this discussion from the KDE lists, as it seems more appropriate
here at debian-devel:)

Hi, KDE guys. Great to hear in your mailinglist that you like the
debian menu system! 

However, two debian menu shortcomings were mentioned in the
above mentioned mailinglist, #1 lack of "#include" in menufiles, and #2 the
updating of user menufiles. I would like to discuss this here.

---------------------------------------------
For #1, I propose to add the following to the menu.sgml documentation file:

DOC> <sect> Include: (one) other feature
DOC> <p>
DOC> 
DOC> More out of curiosity than anything else, I recently read the KDE
DOC> mailinglist. In it I saw some discussion about how good the Debian
DOC> menu system is (whow, thanks, guys!), but one person found a missing
DOC> feature: s/he said you couldn't include other files in the user
DOC> menufiles. Well, actually, it was already possible, but not very well
DOC> advertised. To include the contents of file /usr/lib/menu/somefile,
DOC> add this to your menufile:
DOC> 
DOC> <example>
DOC> !include /usr/lib/menu/somefile
DOC> </example>

---------------------------------------------
For #2, "I don't like it that the user has to run update-menus every time
the admin has installed a new package", the solution isn't all that
simple (i.e., I'll have to actually do something). I see 2 ways to fix it:

  1) (as discussed on the KDE list, and elsewhere)
     make update-menus parse /etc/passwd, read all user homedirs, and
     check if any user has ~/.menu or ~/.menu-method dirs. If so,
     parse them, and update the user "system.fvwmXXXrc" &c. files.

  2) Add a flag (maybe "-u", update) that will (when run as UID != 0)
     cause update-menus to check the modification time of the most recent
     file in /usr/lib/menu (and others), and  compare that with 
     the mod time of ~/.menu-last-ran. If the system admin has recently
     modified /usr/lib/menu, only then update-menus will start the whole
     udating stuff, otherwise it will just do nothing. The idea then is
     that the user simply puts a "update-menus -u" in his ~/.bashrc.
     (of cource, after the run ~/.menu-last-ran will be touched)

I see one advantage of 1):
  It's much easier for the user, and equally easy/difficult for the systemadmin
  
But I also see disadvantages of 1):
  - reduced security. Now update-menus, when started as root, will read
    user-created files. I can fix this by setting the uid properly before
    forking, though. 
  - It may be very impractical to huge systems, with many users that
    have a ~/.menu entry: then every time the system admin installs one
    package, update-menus will have to be run 100 (or whatever) times.
    Granted, with 2) update-menus will also have to be run 100 times,
    but not while the system admin is waiting, and possibly on many
    different computers, if the users use different computers to login.

So, personally I would be in favour of 2), but I do appreciate your
views on this (or, maybe better options).


Thanks,

-- 
joost witteveen, joostje@debian.org

Potentially offensive files, part 5: /dev/random.
`head -c 4 /dev/random` may print 4-letter words (once every approx 4e8 tries).


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: