[QGIS-Developer] Ubuntu Package Releases and GDAL Dependencies

[Sebastiaan Couwenberg]

On 01/11/2018 11:19 PM, Jeremy Palmer wrote:
> On Fri, Jan 12, 2018 at 8:54 AM, Sebastiaan Couwenberg <sebastic at xs4all.nl>
> wrote:
> 
>> 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.
> 
> But I assume Ubuntu universe and multiverse packages could be better
> maintained if someone stepped up to do it.

Yes, but has not happened yet. It seems that people need to be employed
to work on Ubuntu, no one has volunteered to do so.

And this makes sense, Ubuntu is a corporate backed distribution unlike
Debian. And many corporate users choose Ubuntu over Debian because of
that. Why volunteer to do work in that environment when you could be
paid to do so?

>> 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.
> 
> Understood. Maybe Snaps is the solution to all of this, as it provides
> binaries for a larger user base. I'm interested on the community view on
> this.

Snaps and containers just complicate maintenance, you'll have many more
images to update to fix security issues in the packages they contain.

That's the major downside of the isolation they provide.

>> 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.
> 
> In regards to not being locked into companies, I don't see that providing
> more robust community packaging is going to change this situation.
> 
>> This work can be shared with the community, but generally corporate needs
>> differ quite a bit from community needs and
> 
> I'm not really clear what the community vs corporate difference are. What
> are they? I would say that it's a very grey area between who's community
> and who's corporate.

Corporate users have schedules, deadlines and financial interests (e.g.
selling support/training), community users (e.g. volunteers and
hobbyists) generally don't.

>> its cheaper to just keep it all in-house.
> 
> IMHO I don't think this is the case, at least for software with a large
> user base. I also think this approach means that the QGIS LINUX desktop
> uptake for anything other than very large organisations or software
> developers will be low. Look at the Windows and MacOSX environment (even in
> personal home usage), packaging is done once by the provider of the product
> then users will use that packaging without modification. I think many small
> to medium size organisation couldn't justify the resources to employ
> someone to do packaging.

Participating in open source projects for a company generally pays off
when they can share the burden. When a single company supports an open
source project they don't have the benefit of many shoulders lessening
the burden.

I don't know any Windows & OSX users that only use the software included
in Windows & OSX. They all use additional software from elsewhere, and
in the case of OSX generally from open source projects like MacPorts and
Homebrew.

Most users of any software are just that, users. They don't need to
modify it for their needs, they make do with what they have. For the
other users there is open source to adapt to their needs.

In house packaging is not a full time job, it will be among the tasks
for someone doing system engineering or development most likely.

>> 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.
>>
> 
> I think I understand better now. But if the package name includes the
> version number e.g libgdal20 or abi-2-2-2 and that's package is a QGIS
> dependency, how can having a lower ABI version requirement below the
> package version name make any difference? I do except that libgdal20
> (>=2.1) does make some sense, but libgdal20 (>=1.8) seems to be silly.

The "20" in the libgdal20 package name is not the version number, it's
the SOVERSION of the library which is independent of the software version.

Shared library packages need to reflect the library SONAME to have the
package dependencies reflect the required library SONAME. A SONAME
consists of the library name and its SOVERSION, like libgdal.so.20 which
is translated to the package name libgdal20.

Not all libraries do versioning properly, and not all library packages
do naming correctly. Take libarmadillo for example, the maintainer does
not use symbols files nor shlibs to set the version requirements for
packages that link to libarmadillo, which results in segfaults like this:

 https://bugs.debian.org/885971

The minimum required version of the library package was not represented
in the dependencies, so upgrading libgdal20 which was compiled with a
newer version of armadillo did not also cause the upgrade of the
libarmadillo package as it should have.

The version requirements in dependencies are there to help apt do the
right thing when its upgrading packages.

Kind Regards,

Bas