gnunet-developers
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]