Re: [Gnumed-devel] gnumed not finding local db caused by not using correct config file

[Karsten Hilbert]

On Tue, Jul 08, 2008 at 06:32:04PM +0200, Florian Hubold wrote:

> Well, actually you do not give any solution to the problem mentioned.
True enough, sorry.

Which client version (0.2.8.x) are we talking about exactly
? There are solutions but they get a bit more involved the
smaller x becomes.

Two general principles apply:

There should be a writable ~/.gnumed/gnumed.conf, even if
empty. The shell script /usr/bin/gnumed takes care of that
(at least the one we ship).

IF --conf-file is given that file needs to be writable, too
(at least before 0.2.8.10 which is about to be released).

Then, one user still reported some behaviour which I
couldn't reproduce so far: sometimes GNUmed looks at
/etc/gnumed-client.conf instead of
/etc/gnumed/gnumed-client.conf. If that's the case (the log
can tell you) an appropriate symlink solves the problem.

In 0.2.9-to-be this issue is thought to be solved:

- client/wxpython/gnumed.py itself takes care of ~/.gnumed/gnumed.conf
- conf file path handling is centralized and should hence be consistent

> I still need to explicitly tell it which config file to use. If i don't,
> then it does not offer the local db. If i do, it can be chosen in gnumed.
> If you say it should use the client config in /etc/gnumed by default,
> why does it make a difference?
Because it doesn't look at /etc/gnumed.conf by itself. It
looks at /etc/gnumed/gnumed-client.conf (and, apparently,
sometimes, by bug, /etc/gnumed-client.conf). However, if you
say --conf-file=/etc/gnumed.conf it will look at that, too.
But then it'll fail a bit later due to that file not being
writable (and it shouldn't be writable, of course).

> And this also implies that, if it should use the one in /etc/gnumed
> without explicitly telling it, this doesn't have to be writable for the  
> user. Why?
Because it won't try to store user-specific preferences in a
system-wide configuration file because it knows that that
file should not be writable by the user.

It only checks sane locations for writable files (working
dir, home dir, local base dir). However, if it finds
--conf-file it assumed that that file would *always* be
writable because the user knows what she does. That
assumption was fragile and I removed it for good in
0.2.8.10. It was partially removed earlier on but I didn't
find all the spots it occurred.

> The other option (trying out the devel branch) does not sound real
> good for stable packages.
I fully agree.

> But i'll try that out to see if there is any  
> difference.
> Is there any particular branch to try, or should i go for the trunk?
The latter. But don't bother if your plan is to upgrade the
Mandriva packages. It is my job to give you a working stable
release. Expect 0.2.8.10 within the next two days which has
this issue better handled.

> After all the only conclusion for me is that with gnumed 0.2.9 this
> "problem" should not be there anymore?
That is (supposed to be) true.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346