[Live-demo] Re: [OSGeo] #474: include postgis 1.4

[OSGeo]

#474: include postgis 1.4
--------------------------+-------------------------------------------------
  Reporter:  hamish       |       Owner:  live-demo at lists.osgeo.org
      Type:  enhancement  |      Status:  new                      
  Priority:  normal       |   Component:  LiveDVD                  
Resolution:               |    Keywords:  postgis                  
--------------------------+-------------------------------------------------
Comment (by hamish):

 ldd will tell you which shared libraries are used and where the program is
 looking for them. for shared libs the two PostGIS so-names are distinct:

 /usr/lib/postgis/1.3.3/postgres/8.3/lib/liblwgeom.so.1.3
 and
 .../libpostgis-1.4.so.0.0

 but the 1.4 static lib name matches 1.3's soname. unsure what that could
 lead to if compiles try to use static libs; I don't think the .a is
 installed by 1.4, but not sure about that.

 [the next bit is slightly theoretical as it's impossible for me to try all
 build permutations of the varying software, and every machine will be
 slightly different. All I know is that I've fought with enough multiple
 installs of e.g. GDAL over the years to have become highly fastidious and
 very wary about allowing multiple versions of the same library on the same
 production machine]

 For any of the apps that compile after PostGIS 1.4 is installed, which
 version of PostGIS is used may depend on which one ./configure|cmake finds
 first in the LD library path, in a similar way to the issues that follows.
 I can't answer this for sure, autoconf is way too complicated for me to
 audit properly. it's a run it and pray situation.


 The obvious breakage using the proposed change as-is will be if the user
 follows one of a hundred tutorials out there on the web:

 {{{
 createdb -O username gisdb
 psql -d gisdb -f /usr/share/postgresql-8.3-postgis/lwpostgis.sql
 ...
 shp2pgsql -a roads gisdb ...
 # or whatever
 }}}


 but because /usr/local/bin often comes before /usr/bin in the search
 $PATH, the 1.4 ver of shp2pgsql will be used and then it tries to insert
 1.4isms into a 1.3 template ... and the most likely result is kerplunk.

 (again, not tested, but it's a compelling theory)

 so the known needed patch is to remove/rename/move away/whatever those 2
 binaries and their man pages, and without an install manifest I can't say
 what else, if anything. Due to the way that this has been pushed in svn at
 such a late stage of the release cycle, without (or in disregard of) list
 consensus, and with the only justification given being that the new
 version is faster and has better docs, my motivation to work on such
 things is now gone. I've diverted enough energy away from positive
 pursuits already.


 IMHO this is a lot of headaches and auditing work which instantly goes
 away the minute the now 2 week old official debian package hits the main
 archives.


 said my piece and walking away,
 Hamish

-- 
Ticket URL: <http://trac.osgeo.org/osgeo/ticket/474#comment:3>
OSGeo <http://www.osgeo.org/>
OSGeo committee and general foundation issue tracker.