[postgis-devel] Parallel installations

[alex bodnaru]

strk,

strk at refractions.net wrote:
> 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.
> 
do you mean, that a user might safely go back to 1.0.* libs after the
scripts update?
> 
>>this may influence my decision to source lwpostgis_upgrade.sql upon
>>postgis-1.1 installation.
> 
i meant running it automatically.
> 
> 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.
> 
what i meant, is not accidentally running against non-postgis databases,
when in a wild loop.
> 
>>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 ?
> 
yes, it does.
in our setup we have multiple postgresql installations, each with it's
own pg_config, thus we'll call configure --with-pgsql=/path/to/pg_config.
my patches are in to improve configure understanding of the pg_config
output.
> 
>>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.
> 
in debian, using outdated software is widespread custom, so, for
example, openev would finely show a wkt postgis layer, but not a newer
one. that's due to old gdal in debian.
> 
> I'm not sure that cost is worth the benefits.
> 
we both are busy with postgis 1.1.0. (me for debian only). this may
surely be discussed later.
> 
> --strk;
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>