Hi Alex, o Having different postgis versions for the same install would be nice, so if you see an opportunity then it is great. o Only supporting the latest set of tools is not a really good idear, I think. It is overcomplicating things (allthough it is less work to implement, I agree).
If you support the toolset apart from the library, it means you need to implement an additional package and you need to document for the users that you are providing only the latest toolset and not the one that was actually developped with version 0.9. There are strong cases that people need a previous version of a tool (in case of bugchasing when migrating for example), it will be impossible to duplicate the exact original setup when the original toolset suddenly is replaced with a new one (even if the upstream developers did their best to make them compatible: the removal of a bug means that the behaviour is not the same anymore and yes that is not allways what you want!). I think the setup where each version has its own original toolset is better and easier to understand/communicate by/to users. There is a real danger of making the setup too complicated here, I would stick as close as we can to the postgresql-common setup (where in fact psql is also binary compatible with 7.4 and 8.0 backends, but still the old version is called on previous versions of pg) that has the original toolset coupled with each package. The only thing that is needed for that is wrapper scripts that fill in the correct paths based on the version of the cluster (backend) and version of postgis. This means extra work, but it will greatly pay back in simplicity and transparency of use! If needed I can try too help with this, or maybe (also) one of our friends of the list who has more time. The wrapper scripts of postgresql-common are an excelent starting point I think. It could be that we need to store postgis library version for each cluster version and in that case a more generic solution could be that the postgresql-common setup accomodates that: for instance other languages as python and R might also have this versioning problem... Ciao, Floris On 13/10/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Send Pkg-grass-devel mailing list submissions to > pkg-grass-devel@lists.alioth.debian.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-devel > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Pkg-grass-devel digest..." > > > Today's Topics: > > 1. Re: Postgis setup (alex bodnaru) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 12 Oct 2005 17:46:57 +0200 > From: alex bodnaru <[EMAIL PROTECTED]> > Subject: [DebianGIS-dev] Re: Postgis setup > Cc: pkg-grass-devel@lists.alioth.debian.org > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1 > > hi floris, > > since the binary postgis utilities (presently the shp interface) are > been compiled for different postgresql api' we should indeed keep them > with the appropriate postgresql binaries, and should indeed be routed > using the PGCLUSTER directive. > > fortunately, upstream developers stated that newest version of all > utilities should work for postgis 0.9 databases (see the manuals for > special switch). > > thus, utilities may be separed from libraries, and, since the libraries' > names differ at major upgrades (by their file names and the sql > functions script file), we should be able to keep various versions of > the libraries and of the postgis.sql scripts for the same postgresql. > > this kind of setup will be very useful to allow users to upgrade, and to > even make hybrid queries on two different databases. > > of course, we should keep a default postgis to use in > /etc/default/postgis, that would be sourced in order to detect the > script to be loaded by mktemplate_gis, that will anyway be used in > following database operations. > > i'll start working right now on this kind of package split, to allow > paolo to have his data on the same postgresql with different postgis. > > best regards, > > alex > > Floris Sluiter wrote: > > Hi Alex, > > > > I would not advise just one set of tools: > > That set-up will break the moment something changes upstream! It is not > > flexible enough for the multiversion/cluster environment. > > > > Why not do something similar to postgresql-common? > > The binary tools would be located in a directory under > > postgresql/7.4/contrib etc. > > > > You need a wrapper script that will filter which shp2pgsql you need > > (similar to createdb/createlang etc). > > > > so an example call > > shp2pgsql --cluster 8.0/main mytable my.shp > > > > would be directed to the correct binary in postgresql/8.0/contrib (note > > that the clustername 'main' is redundand, but not harmfull, if we only > > allow one version of postgis per version of postgresql, see below) > > > > You can copy most of the script from something that Martin wrote. > > > > I do think it is reasonable to have only one version of postgis per > > version of postgresql. So I do not think it is necessary to do something > > like > > postgresql/8.0/contrib/postgis/0.9/ > > It would be hard to detect which postgis version is needed for which > > cluster in that case, but maybe somebody knows a clever solution to that. > > > > The lwpostgis.sql should also be called from the correct location. I do > > not know if it is possible to load that with createlang for instance, that > > would be much better than loading it directly with psql, because in that > > case the database creator needs to know which path to take. Note that > > createlang already was adapted by Martin to search the correct paths. > > > > Ciao, > > > > Floris > > > > > > > > > >>hi, > >> > >>yes, there is no problem to have postgis coexisting for different > >>postgresql versions. > >>unfortunately, libpostgis0 clash with libpostgis1 on the same > >>postgresql. that's because i have not separated the utilities from the > >>library (waiting for your opinion whether tools from 1.0.4 can operate > >>on data being handled with 0.9.2). > >>the moment you tell me the utilities do that, we can have one utilities > >>package (the latest), and many libpostgis#SONAME#-pg74 (which just > >>differ in #SONAME#). the same with pg80. > >> > >>alex > >> > >>Paolo Cavallini wrote: > >> > >>>Hi Alex. > >>>I miss a point here: is it possible to have libpostgis0-pg7.4 and > >>>libpostgis1-pg8.0 on the same (multicluster) machine, or they conflict? > >>>We're completing our migration, using a slightly different approach from > >>>that > >>>of Floris. A report later. > >>>After that, we'll try to test the tools, as requested by alex. > >>>Many thanks. > >>>pc > >>>At 04:06, mercoledì 12 ottobre 2005, alex bodnaru has probably written: > >>> > >>> > >>>>hi friends, > >>>> > >>>>the moment you came with the information, the postgis project has been > >>>>added a new wiki. > >>>> > >>>>as for the problems: i have attached the up to date postgis-0.9.2 > >>>>package for multiversion architectures. > >>>> > >>>>since i intend to make postgis 0.9 coexist with 1.0, i would be eager to > >>>>know whether the tools that came with latest postgis do still support > >>>>0.9 databases. > >>>> > >>>>at the moment, the packages conflict because the tools are common to > >>>>both of them. thus, i would recomment to install libpostgis0-pg7.4, with > >>>>libpostgis1-pg8.0, to do the transition. > >>>> > >>>>p.s. the java package has been sent for completeness, while it has been > >>>>totally upgraded in later versions. > >>>> > >>>>best regards, > >>>> > >>>>alex > >> > > > > > > > > > > > ------------------------------ > > _______________________________________________ > Pkg-grass-devel mailing list > Pkg-grass-devel@lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-devel > > > End of Pkg-grass-devel Digest, Vol 4, Issue 13 > ********************************************** > _______________________________________________ Pkg-grass-devel mailing list Pkg-grass-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-devel
