Re: [Gnumed-devel] again, trouble applying a bootstrap upgrade (from cvs)

[Karsten Hilbert]

On Wed, Dec 30, 2009 at 01:30:50PM -0800, Jim Busser wrote:

> >> however if I try instead running upgrade-db.sh from within
> >> the above directory,
> > 
> > Which ?
> 
> from /var/lib/gnumed/server/pycommon
> 
> address@hidden:/var/lib/gnumed/server/pycommon$ sudo sh 
> /home/jbusser/gmcvs/gnumed/gnumed/server/bootstrap/upgrade-db.sh 11 12
> [sudo] password for jbusser: 
> Trying to upgrade from version <11> to version <12> ...

OK, that means you are attempting to run the upgrade script
via a system-wide install. The recommended way to do that is
to run - as root - "gm-upgrade_server 11 12" which is a
systemwide GNUmed maintenance command.

Note that a systemwide install can only be of a released
version, namely v11 at most (unless you built .debs locally
and "apt-get install my-deb"ed them).

> >> the script cannot see the conf files
> > 
> > Which ?
> 
> update_db-v11_v12.conf

...

> >> in the bootstrap directory.
> 
> /home/jbusser/gmcvs/gnumed/gnumed/server/bootstrap/

Sure, because there is no such file in

        /var/lib/gnumed/server/bootstrap/

There cannot be because that file didn't exist yet when
that .deb was created by Andreas.

> > If you look at
> > 
> >     /home/jbusser/gmcvs/gnumed/gnumed/
> > 
> > do you see a directory (a link, actually) pointing to
> > 
> >     /home/jbusser/gmcvs/gnumed/gnumed/client/
> 
> what I see is a single link, but it is to /.../server and not to /.../client:
> 
> lrwxrwxrwx  1 root    root      40 2009-12-30 10:50 Gnumed -> 
> /home/jbusser/gmcvs/gnumed/gnumed/server

OK, that's fine. Since that's a local install created from a
tarball it can point to "server/", too.

Does "server/" have "pycommon/" and "__init__.py", too ?

> > under which there eventually is a "pycommon/" ?
> 
> client does have within it pycommon
>
> > Does that 
> > 
> >     /home/jbusser/gmcvs/gnumed/gnumed/client/
> > 
> > contain an "__init__.py" ?
> 
> and also "__init__.py"

That's fine, too, as it comes from the other tarball, the
client one.

You can try adjusting the "Gnumed" link to point to
"client/" rather than "server/" if "server/" does not
contain the "__init__.py" and/or "pycommon/".

I would then assume it to work.

I wonder whether this situation came about by unpacking a
tarball and then running update_tree.sh from it.

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