Re: GEOS 3.5.0
On 17-08-15 17:32, Sebastiaan Couwenberg wrote:
> The API changes don't look very worrying, but I'd like to verify that
> all reverse dependencies still build with GEOS 3.5.0 before uploading it
> to experimental. I don't want to holdup the GCC 5 transitions in case of
> breakage.
I've completed the rebuilds of first dependency level, we need to
untangle the spatialite->postgis->gdal->spatialite circular dependency
to make the build dependencies for all these packages installable with
the new libgeos-c1v5 package.
gdal (1.10.1+dfsg-9 / 1.11.2+dfsg-1~exp4) cannot be built because the
build dependencies cannot be installed. It at least needs spatialite to
be rebuilt with the new geos to not pull in the old libgeos-c1.
osm2pgsql (0.88.0-1 / 0.88.1-1) both build successfully with the new
geos, because the geos transition hasn't started in unstable yet, it's
still not possible to build osm2psql in sid.
ossim (1.8.16-4) like gdal cannot be built because the build
dependencies cannot be installed. It needs at least gdal to be rebuilt
with the new geos first.
player (3.0.2+dfsg-4.2) also has uninstallable build dependencies, but
these seem unrelated to the packages in the geos transition.
The following packages have unmet dependencies:
libopenexr6v5 : Conflicts: libopenexr6 but 1.6.1-8 is to be installed.
libilmbase6v5 : Conflicts: libilmbase6 but 1.0.1-6.1 is to be installed.
libstdc++6 : Breaks: libpqxx-4.0 (<= 4.0.1+dfsg-3) but 4.0.1+dfsg-3 is
to be installed.
postgis (2.1.8+dfsg-1) will also need gdal & spatialite to be rebuilt
with the new geos packages before its build dependencies can be installed.
python-shapely (1.4.3-1) needs a patch to not depend on libgeos-c1 which
has been renamed to libgeos-c1v5 for the GCC 5 transition. The patch has
been forwarded in #795883. The issue was already reported in #795259 so
my duplicate bug has been merged.
spatialite (4.3.0-1) needs postgis to be rebuilt with the new geos, so
but postgis requires gdal & spatialite to be rebuilt first. To untangle
this circular dependency we need to dropping the liblwgeom dependency to
allow spatialite to rebuild with the new geos, after which we can
rebuild gdal and postgis, reinstate the liblwgeom dependency in
spatialite and rebuild spatialite & gdal again. Splitting liblwgeom into
a separate source package may be an option with PostGIS 2.2.
I need to think this issue through some more. It's not specific to the
GEOS 3.5.0 update, and affects 3.4.2 v5 libraries for the GCC 5
transition too.
Transition: geos
libgeos-3.4.2v5 (3.4.2-8~exp3) -> libgeos-3.5.0 (3.5.0-1)
libgeos-c1v5 (3.4.2-8~exp3) -> libgeos-c1v5 (3.5.0-1)
The status of the most recent rebuilds is as follows. Entries tagged
with [+] build successfully after applying the patch from the bugreport.
basemap (1.0.7+dfsg-3) OK
gdal (1.10.1+dfsg-9 / 1.11.2+dfsg-1~exp4) TODO / TODO
osm2pgsql (0.88.0-1 / 0.88.1-1) OK / OK
ossim (1.8.16-4) TODO
player (3.0.2+dfsg-4.2) TODO
postgis (2.1.8+dfsg-1) TODO
python-shapely (1.4.3-1 / 1.5.9-1) OK / OK [+]
spatialite (4.3.0-1) TODO
grass (6.4.4-1 / 7.0.1-1~exp1) TODO / TODO
libosmium (2.2.0-1) TODO
mapcache (1.4.0-1) TODO
mapserver (7.0.0-1) TODO
osgearth (2.5.0+dfsg-4 / 2.7.0+dfsg-1~exp2) TODO / TODO
osmium (0.0~20150428-7f23002-1) TODO
pyspatialite (3.0.1-9) TODO
spatialite-gui (2.0.0~devel2-1) TODO
spatialite-tools (4.3.0-1) TODO
osmcoastline (2.0.1-2) TODO
pyosmium (2.2.0-1) TODO
qgis (2.8.2+dfsg-3 / 2.8.3+dfsg-1~exp1) TODO / TODO
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Reply to:
- References:
- GEOS 3.5.0
- From: Sebastiaan Couwenberg <sebastic@xs4all.nl>