Hopefully I understand Alex correctly, so if I make a mistake then do
not be offended, please.
> > i will implement those calls this way, the moment after the libpostgis
> > and binaries are installed.
The problem is that you cannot properly install/configure them if you
do not deal with the dependencies of different versions. I do not
think it will work if you deal with just the individual postgresql-8.0
Better is to ask of the innocent users to use postgresql-common (it
won't affect normal usage) and deal only with the special case of
having several versions of databases. Postgis packages are then
dependend both on postgresql-common and postgresl-version.
> > 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.
If you mean that nobody is using several databases you might be
mistaken. Martin Pitt is migrating to this new set-up permanently.
Every user can now install several postgresql versions with just one
command. And if that means that postgis is uninstalled (it happened to
me with the old package) it is not acceptable.
The best way to go is to deal with this new scheme, it does solve all
other dependencie problems.
Actually another problem/opportunity is automated upgrading. Having
two versions of the same database installed at the same time allows
ordinary postgresql users to automatically upgrade (at least Martin
Pitt is planning it). Upgrading between postgis versions is not a very
nice task, it misarably fails most of the times, even with the tool
refractions wrote for this.
But let's concentrate on postgis compatability with postgresql-common first.
> > there still are a few issues, and you will be kept updated to be able to
> > test with latest versions.
I do offer my help if you need it...
BTW I became a member of the email@example.com
so I will be receiving those messages as well.
Pkg-grass-devel mailing list