[postgis-devel] Parallel installations (was: Versioning and Branching Rationale)

[strk at refractions.net]

On Mon, Dec 19, 2005 at 05:24:23AM +0200, alex bodnaru wrote:
> hi strk,
> 
> i'm working on debianizing postgis-1.1.
> 
> the funny thing, is that postgis-1.0.4 just entered new packages queue.
> but 1.1 will go on it's path soon.
> 
> i wish to ask you, whether postgis 1.0.x could run on an upgraded
> postgis-1.1 database (for recovery purposes).

Yes. X.Y.Z scripts will run against every X.p.p lib.
When backward compatibility is broken Major increments, and
libs with different Major are known to be safely maintained
on all archs.

> this may influence my decision to source lwpostgis_upgrade.sql upon
> postgis-1.1 installation.

Sourcing lwpostgis_upgrade.sql is a requirement for upgrades.
You can leave w/out it, but your upgrade will not be complete.
postgis_full_version() will keep warning users about this
requirement.

> as i understand, finding a previous 1.* postgis will outrule the case
> there is no postgis installed.

I'm not sure I understood this. When NO postgis is installed you
must source lwpostgis.sql, while when compatible (same Major)
postgis is installed you must source lwpostgis_upgrade.sql.
Swapping the two will always result in errors.

> i have double-checked the configure.in script again, and i am attaching
> it here (sorry not a diff). it adds --with-datadir arg, and is able to
> recognize newer --with-docdir configuration arg in postgresql. the
> postgresql --configure --datadir arg is also recognized.
> those are extremely useful for installing postgis in our current
> postgresql architecture, that allows multi postgresql versions
> installations.

As a general mean to support parallel installation I think we should
use completely custom paths, in a standard way. I just checked
that --prefix=/usr/local/postgis-1.1.0 would not work as expected,
for example. I think it should install *all* of postgis under the
specified prefix.

Not having a specific --prefix specified should act as now, by
using paths extracted by pg_config.

Does it sound fair ?

> also, lwgeom/Makefile has inconsistent install/uninstall directories.
> attached again, sorry.

No problem, committed.

> i hope, that after this release (+debian), we'll find the time to better
> integrate postgis 0.* stuff with current functionality.

The only solution I can think of would be:
- making sure *all* postgis function follow the same (recommended
  but not always used) deserialize/work/serialize path.
- find a way for deserialize() to recognize HWGEOM from LWGEOM
  (hard this far, easier if we tought about it at 1.0.0RC1 time)
- Having serialize() always return the latest representation.

I'm not sure that cost is worth the benefits.

--strk;