Re: [Gnumed-devel] /etc/gnumed/gnumed.conf and 2008-08-27 log

[Karsten Hilbert]

On Mon, Sep 08, 2008 at 11:07:37PM -0700, Jim Busser wrote:

> #4 questions if a config file needs to be better named and suggests that 
> the default packaged releases offer only to connect to the public db 
> whereas the Live CDs could offer both profiles with a preference to local

It does.

> 1. when running from a tarball (or from cvs) there is no gnumed.conf nor 
> any gnumed-client.conf to be found, only
>
>       gm-from-cvs.conf (which is invoked -- referenced -- by gm-from-cvs.sh)
>
> and otherwise there exists only
>
>       /doc/gnumed.conf.example

Correct.



> 2. releases packaging is supposed to copy
>
>       gnumed/client/doc/gnumed.conf.example
> to
>       /etc/gnumed/gnumed.conf
no

>       /etc/gnumed/gnumed-client.conf
yes

> ** but ** my 0.2.8.10x did not contain gnumed-client.conf
The tarball doesn't. If one wants to run from the tarball
they are supposed to use gm-from-cvs.sh which uses
gm-from-cvs.conf. Package maintainers are supposed to do the
abovementioned copy.

> and the pair seem redundant...
It is. In fact /etc/gnumed/gnumed.conf is not used anymore
(the rationale, BTW, is that there is more GNUmed-related
config files in /etc/gnumed/ so we better make the client
config file be named as such).

> ------> Is it intended that we use gnumed-client going forward (0.3.x)
yes

> ------> is it intended that gnumed.conf becomes deprecated after 0.2.8.10x?
yes



> 3. gm-from-cvs.conf file contains profile that provide a choice among  
> multiple databases (public and local db) similar to the /etc/gnumed/ 
> gnumed.conf file in 0.2.8.10x however:
>
> i) how did
>       etc/gnumed/gnumed.conf
> inherit such profiles if it is a copy of gnumed.conf.example which has no 
> profiles?
It would need to be edited to whatever the package
maintainer wants it to be.


> ii) what is the origin of another file found in /etc/gnumed
>       gnumed-public.conf
That's Andreas' decision while packaging for Debian.



> 4. if the intent going forward is to include in .config filenames - 
> client and -server to reduce ambiguity I suggest that in 0.3.2 or 0.3.3 
> we may as well redefine the filename
>       gnumed-public.conf to gnumed-client-public.conf
It's entirely dependant on what Andreas thinks is useful.

@Andreas: Personally I would do away with the -debug and
-public versions of script and conf file. Especially -debug
isn't useful anymore because people can activate debugging
at the login screen.


> I suggest an approach where a package would by default offer only the  
> public database because it only makes sense to offer a local database  
> *after* somebody created one,
That's how the Debian package does it IMO.

> and the person who would do *that* could be 
> the resource to people who figured out only how to connect to public db 
> without a clue how to create and configure a local db
Correct.



> 5. when I first ran GNUmed I had no option to connect to (nonexistent) 
> local db, only the option to connect to the public db. I did not mind so 
> much, since I had no local db anyway, but I thought it funny that the 
> client should know this.
There simply was no profile defined for local.

> After database creation, the client offered me 
> still only the public db
Yes, it doesn't try to find out. There are plans in
PostgreSQL to implement the Avahi service discovery
protocol. When that happens we can implement GNUmed
database detection :-)

> which I fixed by copying into ~/.gnumed/ from 
> /etc/gnumed/ however now that I look at
>       gnumed-conf.gmCfg.bak
>
> If the above preserves a copy of the original ~./.gnumed/gnumed.conf,  
> despite that it contains a preference for
>       profile = local GNUmed database
> it contains no profile for local db and only for public
Don't worry about that file. It is auto-generated.


> 6. when I delete ~./.gnumed/gnumed.conf I can still start the client,  
> presumably because it is looking at /etc/gnumed/gnumed.conf however  
> despite the /etc/ file I was not offered a choice of databases (public 
> and local) but only public.
>
> When I alter /etc/gnumed/gnumed.conf to reverse the order of the  
> profiles (putting local above public) then in the client I am offered a 
> choice of public or local (yet public remains at the top) and this is 
> true whether or not I have an identical copy of this .config in  
> ~/.gnumed


> If I copy this file into ~./ and delete from /etc/gnumed/ then the  
> client will not run thus it does need a config in /etc/ even if there is 
> one in ~/.gnumed/?
It should run (0.3.x anyway).

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