[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#756867: transition: gdal



On 08/13/2014 11:22 PM, Emilio Pozuelo Monfort wrote:
> On 13/08/14 18:51, Sebastiaan Couwenberg wrote:
>> On 08/13/2014 06:18 PM, Julien Cristau wrote:
>>> OK, I'd suggest something like this:
>>> - add Provides: libgdal.so.1-${version} to libgdal1h (${version} being
>>>   1.10.1 or 1.11.0)
>>> - adjust libgdal1h.symbols.* to generate a dep on
>>>   libgdal.so.1-${version} for all c++ symbols
>>>
>>> That way it's clear from the packaging metadata what uses only the
>>> stable C interface and what uses the unstable C++ one, and we know what
>>> to rebuild.  Does that seem plausible?
>>
>> Thanks for the helpful suggestion, it sounds like a nice solution.
> 
> Indeed. That sounds somewhat similar to what qtbase-opensource-src does, with
> the Provides: qtbase-abi-5-3-1 (that change whenever the ABI changes).
> 
>> I'll have a look at implementing it.
> 
> You can probably use dependency-templates on the symbols file, adding a
> libgdal-1.10.1 template and making all the c++ symbols have a dependency on it.
> See the "Advanced symbols file" on deb-symbols(5).

I've implemented the alternative dependency template in the latest
revision of gdal 1.11.0, and I've done a rebuild of all rdeps to see
which of them use C++ symbols.

Most packages use the alternative dependency template. The source
packages for grass, mapserver, ncl, openscenegraph (3.2.0~rc1-5.1),
postgis, vtk, xastir and mapcache don't use any C++ symbols.

It's interesting that the openscenegraph version in experimental does
use some gdal C++ symbols, but the version in unstable does not.

If we want to use this feature to track the GDAL 1.11.0 transition we'll
need to implement it in GDAL 1.10.1 too and binNMU all the rdeps. The
ben file for the 1.11.0 transition could then be:

 title = "libgdal1h";
 is_affected = .depends ~ /libgdal.so.1-1.10.1/;
 is_good = .depends ~ /libgdal.so.1-1.11.0/;
 is_bad = .depends ~ /libgdal.so.1-1.10.1/;

But this would exclude vtk6 which uses symbols introduced in 1.11.0 when
built with it. So I'm not sure if this is the right way forward. Keeping
all packages build depending on libgdal-dev as affected and not
explicitly marking the packages that don't use C++ symbols as good may
be an option.

Would that be acceptable for the Release Team?


The dependency results for the binary packages:

 dans-gdal-scripts           libgdal.so.1-1.11.0, libgdal1h (>= 1.8.0)

 grass-core                  libgdal1h (>= 1.8.0)

 liblas3                     libgdal.so.1-1.11.0, libgdal1h (>= 1.10.1)
 liblas-c3                   libgdal1h (>= 1.8.0)
 liblas-bin                  libgdal1h (>= 1.8.0)

 libmapnik2.2                libgdal.so.1-1.11.0, libgdal1h (>= 1.11.0)

 cgi-mapserver               libgdal1h (>= 1.8.0)
 libmapserver1               libgdal1h (>= 1.9.0)
 mapserver-bin               libgdal1h (>= 1.8.0)
 libmapscript-java           libgdal1h (>= 1.8.0)
 libmapscript-perl           libgdal1h (>= 1.8.0)
 python-mapscript            libgdal1h (>= 1.8.0)
 ruby-mapscript              libgdal1h (>= 1.8.0)

 merkaartor                  libgdal.so.1-1.11.0, libgdal1h (>= 1.11.0)

 ncl-ncarg                   libgdal1h (>= 1.8.0)

 node-srs                    libgdal.so.1-1.11.0, libgdal1h (>= 1.8.0)

 libopenscenegraph99         libgdal1h (>= 1.11.0)
 libopenscenegraph100        libgdal.so.1-1.11.0, libgdal1h (>= 1.11.0)

 osmium                      build depends on libgdal-dev, but none of
                             the binary packages have a dependency on
                             libgdal1h

 postgis                     libgdal1h (>= 1.9.0)
 postgresql-9.4-postgis-2.1  libgdal1h (>= 1.9.0)

 qlandkartegt                libgdal.so.1-1.11.0, libgdal1h (>= 1.8.0)

 sumo                        libgdal.so.1-1.11.0, libgdal1h (>= 1.11.0)

 thuban                      libgdal.so.1-1.11.0, libgdal1h (>= 1.8.0)

 libvtk6.1                   libgdal1h (>= 1.11.0)

 xastir                      libgdal1h (>= 1.8.0)

 libcitygml0                 libgdal.so.1-1.11.0, libgdal1h (>= 1.8.0)
 libcitygml0-bin             libgdal1h (>= 1.8.0)
 openscenegraph-plugin-citygml-shared
                             libgdal1h (>= 1.8.0)

 libgdal1-1.11.0-grass       libgdal.so.1-1.11.0, libgdal1h (>= 1.11.0)

 libapache2-mod-mapcache     libgdal1h (>= 1.8.0)
 libmapcache1                libgdal1h (>= 1.8.0)
 mapcache-cgi                libgdal1h (>= 1.8.0)
 mapcache-tools              libgdal1h (>= 1.8.0)

 libosgearth3                libgdal.so.1-1.11.0, libgdal1h (>= 1.8.0)
 libosgearthannotation3      libgdal1h (>= 1.8.0)
 libosgearthfeatures3        libgdal1h (>= 1.8.0)
 libosgearthqt3              libgdal1h (>= 1.8.0)
 libosgearthsymbology3       libgdal1h (>= 1.8.0)
 libosgearthutil3            libgdal1h (>= 1.8.0)
 openscenegraph-plugin-osgearth
                             libgdal.so.1-1.11.0, libgdal1h (>= 1.8.0)
 osgearth                    libgdal1h (>= 1.8.0)

 saga                        libgdal.so.1-1.11.0, libgdal1h (>= 1.11.0)

 libqgis-analysis2.2.0       libgdal1h (>= 1.8.0)
 libqgis-core2.2.0           libgdal1h (>= 1.8.0)
 libqgisgrass2.2.0           libgdal1h (>= 1.8.0)
 libqgis-gui2.2.0            libgdal1h (>= 1.8.0)
 libqgis-networkanalysis2.2.0
                             libgdal1h (>= 1.8.0)
 libqgispython2.2.0          libgdal1h (>= 1.8.0)
 libqgissqlanyconnection2.2.0
                             libgdal1h (>= 1.8.0)
 python-qgis                 libgdal1h (>= 1.8.0)
 qgis                        libgdal.so.1-1.11.0, libgdal1h (>= 1.8.0)
 qgis-mapserver              libgdal1h (>= 1.8.0)
 qgis-plugin-globe           libgdal1h (>= 1.8.0)
 qgis-plugin-grass           libgdal1h (>= 1.8.0)
 qgis-providers              libgdal1h (>= 1.11.0)
 qgis-sqlanywhere            libgdal1h (>= 1.8.0)

 pktools:                    libgdal.so.1-1.11.0, libgdal1h (>= 1.11.0)

-- 
 GPG Key ID: 4096R/E88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


Reply to: