Re: [DebianGIS] Re: postgis debian packaging
hi floris,
i personnaly have nothing against renaming the packages, but there are a
few drawbacks, specific to this issue:
first, the main debian ftpmasters have rejected once our upload, based
on a much smaller renaming of a source package. so, if we want our
package there, name stability should be stressed, even more than i
personnaly would.
second, package names should somehow follow their contents and
dependency context.
in our examples, part of the packages depend on a specific postgresql
version they are compiled for, but are working for all postgis versions,
(like the utils).
others, depend on the latest postgresql-java (like the java package).
part of them are specific postgis packages (for each version) and depend
on a specific postgresql version (the libraries themselves).
other packages are common to all postgis and postgresql versions (the
common and documentation)
and last but not least, there are packages specific to each postgis
version, but irrespective of the postgresql version (the examples/test).
more than the package dependency, but the files contained in each
package, are also making us split those packages, so that all this bunch
of packages will be installable together without files clashing.
since postgis sponsor, giuseppe, seems to finnaly be more active on the
main upload, we finnaly hope to see postgis in main soon, and i might
focus on packaging the latest postgis-1.1.
the moment postgis will be in, let us see what exactly you wish to
rename, taking of course into consideration continuity (the replaces
clause) and compatibility (the dependencies as described above), and we
might together come to a better postgis deb.
alex
F.Sluiter wrote:
> 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: