Re: Menu package, user updates, include (Was: KDE/SEUL)
> joost witteveen writes:
> > 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).
>
> Yeah, that's a problem.
>
> > 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)
>
> The main disavantage of these 2 solutions is that the user-created
> menu files will still, in most cases, duplicate most of the system
> ones.
>
> As an example, if I just want, as a user, to add a menu entry for a
> program in say ~/bin/, I still have to recreate ALL menu entries.
What "menu files" do you mean?
Do you mean the "menuentry files", that
usually reside in /usr/lib/menu? In that case, you are wrong, as
update-menus, when started by a user, already reads ~/.menu (the
user menuentryfiles), and then /etc/menu and /usr/lib/menu, and
/usr/lib/menu/default. (and menuentry files that are read first
take presidence). Please read the docs. (/usr/doc/menu/html/*).
Or do you mean "menu- generated files", like system.fvwm2rc etc.
Also in that case you are wrong, as update-menu only runs the
scripts in ~/.menu-method, and not the ones in /etc/menu-method/.
So the user can choose what scripts to re-run and what not.
> Going further, it would be nice if we could have update-menus run only
> when the relevant menu has been modified on the system level, more
> recently than on user level. That would signicantly reduce the CPU
> load dedicated to menu-generation.
Unfortunately, that is not possible. At least not with something that
is as complex as generating menufiles for _all_ available Window-Managers
and even www stuff. Some of those wm's want first the submenus, then the
rest, some what it the other way around. I'd have to parse those file, that
all have completely different structures, to see where to add/remove a
line. And, still, I'd have to parse the whole file (no, the world is
bigger than just fvwm2. That's about the only one that can even read in
extra files (like #include) in it's system.fvwm2rc, but also here it's
really difficult to build it the way you seem to think is easy).
> This could be achieved by using a set of one time-stamps per
> (sub-)menu on system level, and one time-stamp per
> user-level-generated (sub-)menu.
Checking what menuentry files are changed is _easy_. I used to even do
this in older versions of menu, that actually tried to accomplish something
like what you do. But even for the much simpler system then, the cache
files kept running out of sync. It was really difficult (nay, impossible)
to keep those cache files in order -- I don't really remember all the
details of it, but the bottum line was: don't create cache files.
It just doesn't work, and, the way I see it, is actually not going to
save you as much as you think. Actually, I think that even fvmw2 (the
only one that can even do what you want) would slow down on startup
significantly if you start to put every submenu (there are _many_!) in
a different file. All those different submenu-files have to be read
on _every_ startup. Not very good.
> I think of using something like menu files with "needs=login-shell",
> and bash/tcsh/whatever providing methods to handle this.
This I don't quite understand. Would the "login-shell" ask for a passwd?
If so, how does a not-yet-logged-on user specify that he wants to
actually run that menuentry?
> With a bit
> of work, setting variables would work too, and we could then allow
> programs to be globally configured using environment vars, which we
> can't (and is AFAIK forbidden, maybe because we don't have such a
> mechanism) for now.
More like it's better to make sure the programs run properly without
the environment vars. Setting all those environment vars in /etc/profile
(or wherever) takes time, and if 1000 packages start to do this, I
will not be able to logon any more on my system.
(that is, if 1000 packages do it properly, i.e. in their own file.).
--
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: