[QGIS-Developer] Ubuntu Package Releases and GDAL Dependencies

[Jeremy Palmer]

Hi Bas,

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.


>
> 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.

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 siutation.


> 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.


> 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.


> 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.

Cheers,
Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20180112/119b4c64/attachment-0001.html>