Re: [DebianGIS] Re: postgis debian packaging
Hi Alex and gis-friends,
(Note: I am quite stubborn ;-) )
I do not understand why postgis needs a different treatment then for
instance R. (plr), I'll try to explain how I did my setup below.
(Please note: I'm not discussing the jdbc driver,
only pgsql2shp, shp2pgsql, liblwgeom.so/libpostgis.so and the scripts).
> Alex:
> splitting utils from postgis-lib is because latest utils support all
> postgis versions. thus, bundeling utils together with libs will clash
> for different postgis.
I do not understand that, because: you would not install the tools in
the same directory or multiple different postgis versions with the
same postgresql version (or at least I do not see a sound reason or
way to implement that possibility yet)!
That should be automatically handled with the version number in the
package and package restrictions.
I have different versions of postgis installed for different
postgresql versions, including the tools, and it is not a problem, no
libraries or tools clash.
In my humble opinion it is not a desirable way to split the postgis
out of the postgresql directories, or do the postgis1, postgis2
numbering... It complicates things a lot more then just staying with
postgis as a contrib to postgresql as upstream is by default providing
it and Martin Pitt is treating the contrib without problems. However
they are allways bundled with the postgresql version or a separate
package is available for each pg_version!
So I propose:
you can choose between installing postgis0.9.2, 1.0.0 or 1.0.5 for a
specific postgresql:
postgresql-7.4-postgis version: 0.9.2
postgresql-8.0-postgis version: 0.9.2
postgresql-8.1-postgis version: 0.9.2
postgresql-7.4-postgis version: 1.0.0
postgresql-8.0-postgis version: 1.0.0
postgresql-8.1-postgis version: 1.0.0
postgresql-7.4-postgis version: 1.0.5
postgresql-8.0-postgis version: 1.0.5
postgresql-8.1-postgis version: 1.0.5
Which would indeed (only) make 9 packages!
So pg7.4 either with postgis0.9 or postgis1.0 (independend of the
amount of clusters you have for this version of postgresql7.4)
and choosing (historically grown...)
pg7.4_pgis0.9
pg8.0_pgis1.0
pg8.1_pgis1.0.5
Results for me in:
The paths to tools and libraries in my setup:
/usr/lib/postgresql/7.4/bin/shp2pgsql (version: 0.9.2)
/usr/lib/postgresql/8.0/bin/shp2pgsql (version: 1.0.0)
/usr/lib/postgresql/8.1/bin/shp2pgsql (version: 1.0.5)
/usr/lib/postgresql/7.4/bin/pgsql2shp (same versions...)
/usr/lib/postgresql/8.0/bin/pgsql2shp
/usr/lib/postgresql/8.1/bin/pgsql2shp
/usr/lib/postgresql/7.4/lib/libpostgis.so (same versions...)
/usr/lib/postgresql/8.0/lib/liblwgeom.so
/usr/lib/postgresql/8.1/lib/liblwgeom.so
/usr/share/postgresql/7.4/contrib/lwpostgis.sql
/usr/share/postgresql/7.4/contrib/spatial_ref_sys.sql
/usr/share/postgresql/8.0/contrib/lwpostgis.sql
/usr/share/postgresql/8.0/contrib/spatial_ref_sys.sql
/usr/share/postgresql/8.1/contrib/lwpostgis.sql
/usr/share/postgresql/8.1/contrib/spatial_ref_sys.sql
(I do not use the migration scripts etc so I didn't copy them, but I
guess you'd put them in the contrib directory (possibly in a subdir
contrib/postgis/)).
> Alex:
> i will consider renaming the packages later, but this will move name
> focus from postgis to postgresql-version, while not all postgis packages
> depend on a specific postgresql version.
Yes in fact they do allways depend, the are compiled against a
specific version of postgresql and also tested with specific versions
of postgresql. I'm not saying that this wil be the case now (the might
be the same source, or new versions are better), however it will be in
the (near) future, when more versions of postgresql and postgis are
written. So in that case installing a newer version could break a
perfectly functioning old version!
The beauty of the multicluster/multiversion environment is that
(because of pg_wrapper) you can have multiple versions together, which
will not be possible in the proposed postgis set-up!
> Alex:
> of course, pg_wrapper support is full and working, and will improve a
> little as martin will upload a few changes i've asked him to.
So why is it a problem to bundle the tools? The main function of the
pg_wrapper scripts is to avoid clashing of tools, the libraries are
handled by postgresql, provided you put them inside the postgresql
install.
The only thing one needs to know if accessing their default database cluster:
shp2pgsql myshape.shp ...
If accessing another cluster (a little more knowledge required):
shp2pgsql --cluster 8.1/main myshape.shp ...
Which would access a different tool.
shp2psql would actually call a wrapper script that sorts out the
correct path and you would not have to change it when installing a new
postgresql/postgis version!.
(Note: I type the paths to the tools manually, I do not have the
pg_wrapper script set-up, it is not that bad, considering that you do
not use it as often. Sorry, I lied here: I know they are binary
compatible and I have a symbolic link in my path to the latest
version, however I occaisionally do use the older versions!).
Accessing the lwpostgis.sql scripts is straightforward, because a user
would see the path to it, or the user could use a template database.
Hacking createlang for postgis might also be a nice way of doing it
but would need cooperation of upstream or Martin Pitt. (something like
createlang --cluster 8.1/main postgis...)
If in the future it turns out that we do need postgis1 and postgis2,
we can allways change that. But for now I would keep it as simple and
clear as possible.
So if you find the above a very bad idear, would you take the time to
explain to me why?
Best regards,
Floris
Reply to: