[QGIS-Developer] Ubuntu Package Releases and GDAL Dependencies

[Sebastiaan Couwenberg]

On 01/11/2018 08:23 PM, Jeremy Palmer wrote:
>> You should have a look at UbuntuGIS development to see that it is mostly
>> the work of one person now. Packages are updated for OSGeo-Live and copied
>> to ubuntugis-unstable, after a while (no policy or guidelines) the packages
>> from ubuntugis-unstable get copied to ubuntugis-stable.
>> This generally happens during an Ubuntu releases lifecycle, not ideal for
>> production systems.
>>
> 
> Thanks for the information. Good points.
> 
>> For production systems one should not rely on 3rd party repositories,
>> other than the one the company maintains itself where it does all the
>> integration work.
> 
> This is where I'm a little on the fence. I would much rather do it well for
> all of the community, than just for my organisation. At the end of the day
> my organisation doesn't need to apply special patches for our desktop
> usage. But I agree applications that are developed using these libraries or
> require core customisation definitely need a in-house managed repository.
> 
> Our organisation needs to have a QGIS LTS release supported that works on a
> Ubuntu LTS release. Correct me if I'm wrong, but QGIS.org seems to provide
> this now with the current release/LTS Debian repositories. It's the QGIS
> critical dependencies which have varying policies of support that are the
> problem. This seems to be a problem of resources/volunteers at the project
> and the distribution packaging level. For example in the GDAL project, 1.10
> and 1.11, which are the current GDAL versions in Ubuntu 14.04 and 16.04
> haven't been maintained for many years. Only 2.2.X seems to be getting any
> current support currently (thanks Even!). I guess this is part of the wider
> problem that was identified by Paul Ramsey in
> http://blog.cleverelephant.ca/2017/08/foss4g-keynote.html. Somehow we need
> to solve this for the wider geospatial OS community.

When you need newer versions of the core geospatial libraries like GEOS
& GDAL than what is provided in the Ubuntu LTS releases, you'll need
some 3rd party repository because Ubuntu doesn't provide backports. The
geospatial packages in Ubuntu are actually not actively maintained at
all, active maintenance only happens in Debian and Ubuntu just copies
its packages from Debian.

The nature of LTS releases is that they don't change the versions of the
packages they provide, Debian stable, Ubuntu LTS and RedHat/CentOS don't
differ much in the respect.

When the users of those distributions do have a need for newer packages
they need to get backports somehow, either through some 3rd party
repository over which they have no control, or their own in-house
repository which they do control. The latter is the best option to
prevent any surprises when the repository gets new versions, it does
require integration work to rebuild all related packages to work with
the new versions of the libraries in question.

> I'm not sure if this problem is something that can be done by OSGEO or some
> other alliance of companies. My feeling is no one company can currently
> provide this service as it requires expertise across the full stack, or
> enough scale in business to centralise support for the whole stack.

As long as the geospatial packages in Debian and UbuntuGIS are
maintained by volunteers the users of those packages can't expect more
than work on a best effort basis. No one is employed to maintain these
packages for the wider community, although there seems to be a need at
least for corporate Ubuntu users. Mapgears sponsored work on UbuntuGIS
in the past, but that was apparently not successful enough to continue.

One of the benefits of open source is that companies are not dependent
on suppliers, and can employ people to the needed work in-house. This
work can be shared with the community, but generally corporate needs
differ quite a bit from community needs and its cheaper to just keep it
all in-house.

>>> I've also noted that the 2.18 binaries produced for the 14.04 and
>>> 16.04 packaging has inconsistent dependency requirements. e.g 2.18.15
>>> 14.04 64bit :
>>>
>>> qgis - gdal-abi-2-2-2, libgdal20 (>= 1.8.0) qgis-providers = libgdal20
>>> (>= 2.2.0) qgis-server - libgdal20 (>= 1.8.0) libqgis-dev -
>>> libgdal-dev (>= 1.10.1-0~) libqgis-core - libgdal20 (>= 2.2.0)
>>> libqgis-app2 libgdal20 (>= 2.0.1)
>>
>> The version requirement for libgdal20 are determined based on which
>> symbols the code in the dependent package uses, qgis & qgis-servers don't
>> use any symbols introduced after GDAL 1.8.0, libqgis-dev does but no
>> symbols introduced after GDAL 1.10.1, etc.
> 
> Ok thanks. What's the practical use of this approach if it's tied to
> gdal-abi-2-2-2 anyway?

I don't understand the question.

The version requirement in the dependencies reflect the minimum version
the code in the dependent package requires to work with the library.
Some parts of qgis use features introduced in GDAL 2.x whereas other
parts don't use features introduced after GDAL 1.8.0. Because the
various parts of qgis are split into separate packages you get the
different version requirement for gdal for those parts.

There is generally only a single gdal package in the repositories like
in Debian and Ubuntu. Only when one adds a 3rd party repository like
UbuntuGIS is another version of the gdal package available, and you get
integration issues like qgis being uninstallable with the UbuntuGIS
dependencies after gdal is updated there but qgis hasn't been rebuilt
with the new version yet.

Kind Regards,

Bas