thanks for pointing me to those issues. they are instructive as of the
dilema on which binary to run, and against which server.
i will implement those calls this way, the moment after the libpostgis
and binaries are installed.
mind you, the difference between the older libpostgis package and the
present one, relays in the low level support for concomitently installed
postgresql of multiple versions, both at build time and at runtime.
there still are a few issues, and you will be kept updated to be able to
test with latest versions.
> Hi All,
> I did have a short time to look at the new package Alex prepared.
> Correct me if I'm wrong, but I think it is not using the correct
> set-up for postgresql, you have to use postgresql-common for this to
> Martin Pitt designed a new setup, that will enable running several
> versions of postgresql at the same time. If people don't want that, it
> works as before...
> A description of what this is about is here:
> The new package that implements this is postgresql-common. It is vital
> to postgis to conform to this structure!
> It does solve a whole lot of dependencies in a rather elegant way.
> Currently I have two cluster versions running with several databases
> and it is flawless, allthough not completely userfriendly yet. Both
> versions use postgis (one postgis0.9, the other uses postgis1.0.3).
> The Gist is this:
> All applications for postgresql are wrapped with a script that checks
> where to send the command and each user has a default version.
> If you only have one version (postgresql 8.0), everything is fine,
> everybody just types psql and it works.
> Now if you have two versions (I have postgresql 7.4 at port 5432 and
> postgresql 8.0 at port 5433) it works like this:
> $ pg_lsclusters
> Version Cluster Port Status Owner Data directory
> 7.4 main 5432 online postgres /var/lib/postgresql/7.4/main
> 8.0 main 5433 online postgres /var/lib/postgresql/8.0/main
> $psql -f dowhatever.sql (connects to my default version 7.4)
> $psql --cluster 8.0/myclustername -f dowhatever.sql
> He has developped several tools to control all this (pg_ctlcluster is
> the main script).
> For postgis this would mean:
> Versioning for packages:
> I suggest a new naming convention:
> Package versions will follow postgis versions so the version of all the
> above packages will be currently 1.0.x.
> Allthough it looks like you suddenly maintain 3 packages, the set-up of
> postgresql-common is such that this will be minimal effort.
> For the loader and drivers I suggest following the setup of
> postgresql-common: each binary will find its place in the bin directory of
> the appropriate postgresql version.
> calling shp2pgsql will invoke a wrapper script that checks which cluster
> version you use as default, or if you want to connect to another. You
> can use the scripts Martin wrote as a base for this.
> About your Errors:
> What could be the case is that your install doesn't allways follow the correct
> path to the new postgresql 8.0 (and partially uses libs from 7.4)
Pkg-grass-devel mailing list