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

[Karsten Hilbert]

On Wed, Dec 30, 2009 at 06:49:52PM -0800, Jim Busser wrote:

> > 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).
> 
> Ok, this means I misunderstood and maybe even broke information on
> 
>       http://wiki.gnumed.de/bin/view/Gnumed/ServerUpgrade
> 
> It has one section on "local upgrade" and one on "net upgrade". I had assumed 
> these in both cases to refer to the same, single, system-wide postgres 
> database "gnumed" and that with the "local upgrade" one simply depends on 
> already-downloaded files and which could therefore be run without internet 
> connection:
> 
>       sh upgrade-db.sh 10 11
> 
> I had assumed the "net upgrade" to achieve the same thing, but using an 
> internet connection.

That is pretty much true but its truth is orthogonal to what
is meant by the above systemwide vs local.

The GNUmed database upgrade/installation process is two-fold:

1) put the installer/data files on the system
2) install/upgrade the database from them

There are several ways how 1) can come to be:

        apt-get install gnumed-server
        (or whatever the distro-specific incantation would be)

        this would put the installer from the distro repos onto
        the system such that 2) can happen from anywhere in the
        system, by, say: /usr/sbin/gm-bootstrap_server (or some such)



        apt-get install /home/user/downloaded-debs/gnumed-server-v5.2.deb

        this would do pretty much the same as above except would
        not pull the .deb from the distro repo



        download and unpack a tarball manually or with
        gm-net_install/upgrade_server.sh

        this will put the installer into a user-local directory
        (the script uses ~/.gnumed/server-installation/),
        thereby it can NOT be invoked system-wide but rather
        only by the downloading user manually which would
        include cd'ing to server/bootstrap/ and calling
        ./upgrade-db.sh x x+1 (or whatever other script there
        seems useful)



        close CVS to your local hard drive

        this will result in pretty much the same situation as
        downloading a tarball



It doesn't really matter how the files get onto your machine
- they will always come from the net (or rarely from other
media). What does matter is where they end up: either
user-local only invocable by that user (sudo'ed to root, of
course) from within that directory or systemwide invocable
by any user with sufficient rights (root only works, of
course) from any directory.


> After examining net_upgrade-gnumed_server.sh its differences include:
> - needing the internet connection
> - depending on an official release from 
> http://www.gnumed.de/downloads/server/ and therefore unable to be run against 
> what is in the CVS between releases

Yep, that's a limitation of that script.

> "Local upgrade" *can* be applied to an unreleased database version but
>
> 1) as previously warned should not be on a live DB because
> there is no plan of fixups to non-official (interim)
> versions of the database such as is the as-yet unreleased
> v12 and

CVS and .rc tarballs (or even packages) *will* include all
fixup scripts from the released version to whatever interim
version one upgrades to.

Ah, wait, you probably mean that those interim database
should then not be *used* as live DBs. Yes, that's correct !

> 2) the user creates or repoints, in gnumed/gnumed/ a Gnumed symlink pointing 
> at the full specification to /client 

A server *tarball* *will* contain the needed __init__.py and
pycommon/ within server/ while a copy of the CVS tree will
not (or rather only in client/)

> Do I now better understand the above to be only (at best)
> partly correct, and that it is possible to have a systemwide
> version of a released Gnumed database (such as v11) and a
> non-systemwide (local user only) version of, say, a
> pre-release v12?

This is partially confused, too:

The GNUmed database installer does not make any assumptions
of where the database actually ends up after bootstrapping:

- it can be on the local machine
- it could be on another machine

- it can be a systemwide cluster of PostgreSQL as would be
  typical for, say, Debian
- it could also be an cluster of PostgreSQL running locally
  from within a user's homedir

- it can be the single cluster of PostgreSQL running on a
  machine
- it could be any of a number of clusters of same-version
  or different-version PostgreSQL clusters running on a
  single machine (on different ports)

- each of v10, v11, and v12 can be in any of the above
  PostgreSQL clusters (only that both source and target
  version need to be in the same cluster)

> Also at the point where an official database release

... (v12) ...

> becomes available, and assuming upgrade-db.sh was not run
> against a non-release script in CVS but instead from an
> official server tarball or deb, is there any difference in
> what would be achieved from any among
>
>       upgrade-db.sh 11 12
>       net_upgrade-gnumed_server.sh
>       gm-upgrade_server 11 12

I do think given the circumstances you laid out those should
result in the same thing. There are slight differences,
though:

1) would need to be run from with server/bootstrap/
        - requires files to be available locally
2) would have to be run from where gm-net_upgrade_server.sh resides
        - requires internet access
3) can be run from anywhere in the system
        - requires a server deb to be installed

> and does it matter whether as root or as sudo?

No, it should not, although for gm-upgrade_server it would
be extraneous as that is only available to root anyways.

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