[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNUnet-developers] Libgksu & configuration support
From: |
Christian Grothoff |
Subject: |
Re: [GNUnet-developers] Libgksu & configuration support |
Date: |
Wed, 19 Dec 2007 12:53:17 -0700 |
User-agent: |
KMail/1.9.7 |
On Wednesday 19 December 2007, Milan wrote:
> I've just commited yesterday my updated version of configuration support
> from gnunet-gtk. Now, gnunet-gtk adapts itself to the chosen config file
> to launch gnunet-setup:
> - if libgksu2 was not enabled at build time, it checks whether you have
> write permissions to the file, and if this is the case allows you to
> start gnunet-setup
> - if libgksu2 was enabled, it checks the perms and starts gnunet-setup
> under current user or asks for root rights if needed
> The button's sensitivity reflect what you can do.
Great!
> Nils, you may want to have a look to that code since most of it is
> reusable with Qt adding little changes (mainly with Glib wrappers - Gtk
> Widgets are only used a few times). I hope this feature can be very
> useful to people that don't like command line and don't know where and
> how to look.
>
>
> What I'm wondering is how I can do the same for starting gnunetd, which
> currently only works on very few cases. I can look into the config file
> to know what user to use, but how could I start gnunetd using default
> libgnunetutil functions, since libgksu only works with independent
> programs? Starting gnunetd cleanly requires to take into account
> parameters that every deistribution may change (nice, ionice, pidfile...).
Ok, assuming that what you're trying to talk about is starting gnunetd from
gnunet-gtk and your issue is that the existing gnunet-util "start-daemon"
functions wouldn't work -- why not just avoid using them entirely if you use
libgdksu? As for process priorities,pidfile, etc, I don't think those are an
issue since you can just read the values from gnunetd.conf (if gtksu needs
them) -- remember, you can load a 2nd configuration file using the new
GNUNET_GC_* apis (so you can have both a gnunet.conf and a gnunetd.conf in
memory at the same time and know which one you're using when).
So I think my answer is: you don't have to use the gnunet-util functions to
start/stop gnunetd if they are not appropriate. Does that answer your
question(s)?
> Do you have any idea? I can see one: we should store the command line
> the distribution wants to use to launch gnunetd in our config file, so
> we can get it from gnunet-gtk. But maybe there are better ones...
>
> Cheers
>
>
> PS: would it make sense I ask Debian to set dependencies for gnunet-*
> packages so that the whole series (gnunet-server, gnunet-gtk,
> gnunet-qt...) require from each other the very same version (eg =
> 0.7.2c)? At the moment, you can use gnunet-gtk 0.7.1 with gnunetd
> 0.7.2c, which brought me a crash in Ubuntu.
Well, having all of them require an exact match may not always be correct. For
example, we may not always have a new gnunet-qt/gtk/fuse release when we
change GNUnet, and these versions maybe compatible (sometimes).
Now, the 0.7.3 release should be flagged to conflict with any previous release
of any of the other packages. And whenever we break compatibility like this,
a conflict should be put in. But I don't think we should by default always
require exact matches (since this may sometimes force unnecessary package
updates).
My 2 cents.
Christian