Re: Bug#791045: transition: geos (spatialite->postgis->gdal->spatialite circular dependency)
On 18-08-15 21:24, Sebastiaan Couwenberg wrote:
> On 17-08-15 22:16, Sebastiaan Couwenberg wrote:
>> On 17-08-15 21:50, Sebastiaan Couwenberg wrote:
>>> 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.
>>>
>>> [...]
>>>
>>> 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.
>>>
>>> [...]
>>>
>>> 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.
>>
>> To deal with the spatialite->postgis->gdal->spatialite circular
>> dependency the process should probably be:
>>
>> * Upload geos to unstable to start the GCC 5 transition
>> * Upload spatialite (4.3.0-2) to unstable, drops liblwgeom dependency
>> * File RC bug on spatialite (4.3.0-2) about liblwgeom regression to
>> prevent testing migration, and have the RC bug block the geos
>> transition bug (#791045) too
>> * BinNMU gdal with spatialite (4.3.0-2) in unstable
>> * BinNMU postgis with rebuilt gdal & spatialite in unstable
>> * Upload spatialite (4.3.0-3) to unstable, reinstates liblwgeom
>> dependency
>> * BinNMU gdal with spatialite (4.3.0-3) in unstable
>> * BinNMU postgis with rebuilt gdal & spatialite in unstable
>
> This process allowed the successfull completion of the rebuilds for GEOS
> 3.5.0. The results are summarized below.
>
> Some of the reverse dependencies cannot be built because the protobuf
> (#791246), wxwidgets3.0 (#791311) & openscenegraph (#791231) transitions
> haven't started yet causing uninstallable build dependencies and link
> failures. Details are available in my recent post in the 'GEOS 3.5.0'
> thread on debian-gis@:
>
> https://lists.debian.org/debian-gis/2015/08/msg00082.html
>
> The attached ben configuration updates the tracker for the geos
> (3.5.0-1) packages that I'd like to upload instead of the current 3.4.2
> ones with only the v5 rename. I will require a pass through NEW for
> libgeos-3.5.0.
Thanks to the speedy binary-NEW processing by Scott Kitterman we have
GEOS 3.5.0 ready in experimental, I just uploaded the second revision
with the symbols updates for the other architectures. It's ready for the
GCC 5 transition now.
@Release Team, please update the tracker for geos-3.5.0.
https://bugs.debian.org/cgi-bin/bugreport.cgi?filename=geos-3.5.0.ben;msg=54;bug=791045;att=1
Because geos is also a (build) dependency of gdal, maybe we should start
the geos transition before starting the gdal transition (#756867). The
gdal transition is needed to unblock the netcdf (#791215), libdap
(#791114), qscintilla2 (#791257) & spatialindex (#791332) transitions.
The latter two only need a rebuild of qgis but this requires gdal to be
rebuilt with the new libdap first.
> Transition: geos
>
> libgeos-3.4.2 (3.4.2-7) -> libgeos-3.5.0 (3.5.0-1)
> libgeos-c1 (3.4.2-7) -> libgeos-c1v5 (3.5.0-1)
>
> The status of the most recent rebuilds is as follows.
>
> basemap (1.0.7+dfsg-3) OK
> osm2pgsql (0.88.0-1 / 0.88.1-1) OK / OK
> python-shapely (1.5.9-1) OK
> spatialite (4.3.0-1 / 4.3.0-2 / 4.3.0-3) FTBFS / OK / OK
> gdal (1.10.1+dfsg-9 / 1.11.2+dfsg-1~exp4) OK / OK / OK / OK
> postgis (2.1.8+dfsg-1) OK / OK
> ossim (1.8.16-4 / 1.8.16-5) FTBFS / OK
> player (3.0.2+dfsg-4.2) FTBFS
>
> grass (6.4.4-1 / 7.0.1-1~exp1) FTBFS / FTBFS
> libosmium (2.2.0-1 / 2.3.0-1) FTBFS / OK
> mapcache (1.4.0-1) OK
> mapserver (7.0.0-1) OK
> osgearth (2.5.0+dfsg-4 / 2.7.0+dfsg-1~exp2) FTBFS / FTBFS
> osmium (0.0~20150428-7f23002-1) FTBFS
> pyspatialite (3.0.1-9) OK
> spatialite-gui (2.0.0~devel2-1) OK
> spatialite-tools (4.3.0-1) OK
>
> osmcoastline (2.0.1-2 / 2.1.0-1) FTBFS / OK
> pyosmium (2.2.0-1 / 2.3.0-1) OK / OK
> qgis (2.8.2+dfsg-3 / 2.8.3+dfsg-1~exp1) FTBFS / FTBFS
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Reply to: