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

Re: GDAL 2.2.0

On 04/14/2017 09:14 PM, Even Rouault wrote:
>> The first beta for GDAL 2.2.0 has been released, and the gdal package in
>> experimental has been updated.
> Thanks. That's great !

Because of the new gdal-data package it needs to be reviewed by the
ftp-masters to pass the NEW queue, though. After that we can also upload
libgdal-grass. And do a round of rebuilds of the reverse dependencies to
find out if anything breaks that would be a blocker for the transition
(after the stretch release).

>> While we have librasterlite2 in the archive, the RC0 version doesn't
>> have the required functions to enable the support in GDAL.
> Yes, the future librasterlite2 1.1 will be needed. Sandro Furieri told me that a 1.1.0-RC0 
> should be released rather soon.

I'm looking forward to it.

>> We do have Fyba, so the SOSI support was enabled.
>> We also have SFCGAL, but since many users complain about the
>> OpenSceneGraph dependency chain pulled in via libsfcgal, I've not
>> enabled the support for now. Once the new SFCGAL release is out which
>> splits the OSG support into a separate library, we can reconsider
>> enabling the support in GDAL. Development of SFCGAL is not very active,
>> which doesn't inspire confidence in its future supportability in PostGIS
>> & GDAL.
>> Because of the minor version bump, now was a good time to move the data
>> files (in /usr/share/gdal/<MAJOR>.<MINOR>) from libgdal20 to its own
>> architecture independent gdal-data package (like libproj & proj-data).
>> This leaves only the shared library in libgdal20 which is more
>> appropriate.
> A hint just in case (I didn't look how the dependency was expressed): the data package 
> should be considered almost as mandatory when you install the library, otherwise many parts 
> will not work properly. 

It's a strict dependency of libgdal20:

 Package: libgdal20
 Architecture: any
 Section: libs
 Depends: gdal-data (>= ${source:Version}),
 Recommends: proj-bin
 Breaks: libgdal1h (<< 2.0)
 Provides: gdal-abi-2-2-0

This is analogous to the proj-data dependency of libproj12 (which
doesn't have a version required, though).

Any package that depends on libgdal, will get the gdal-data package
installed too. This keeps the installed files the same as when they were
bundled in the libgdal package.

>> A nice side effect will be that eventually many systems
>> will have the gdal-data package installed likely making gdal an key
>> package (exempt from testing auto-removal) as proj is also thanks to
>> proj-data.
> Not sure to have understood what you meant.

Because the libproj packages depend on proj-data it is installed on
every system that has any version of the library installed. This causes
the high popcon score for this package, see:


Packages installed on >= 5% of systems reporting their popcon data are
considered key packages which won't be removed automatically from
testing when they are affected by release critical bugs.

The dependencies of gdal which haven't changed their SONAME since the
oldstable release are installed on more than 9000 systems passing the 5%

Due to libgdal having changed SONAMEs in the past releases, there isn't
a single binary package built from the gdal source package that passes
5% threshold. The library package names change to match the SONAME, but
the data package won't. It will be installed on every system that has a
libgdal installed from version 2.2.0 on.

I previously mentioned the key packages maintained by the Debian GIS
team in this thread:


The common theme among the packages listed there are that they're
dependencies of GDAL. While those packages also get installed as part of
the dependency chain of other packages, GDAL is the cause of a
significant chunk of those installs. Adding the number of installs for
the various libgdal packages also passes 9000 systems:

 ~6300 libgdal1h
 ~3100 libgdal20
  ~500 libgdal1
  ~200 libgdal1i


Kind Regards,


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

Reply to: