<div dir="ltr">Hi Bas,<br><div class="gmail_extra"><br><div class="gmail_quote">On 5 October 2017 at 11:01, Bas Couwenberg <span dir="ltr"><<a href="mailto:sebastic@xs4all.nl" target="_blank">sebastic@xs4all.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes, Debian distributions will only ever have a single gdal package, Ubuntu by extension will too (because they just copy the packages from Debian) although newer versions are available in the UbuntuGIS PPA (which is a separate repository from the Ubunu ones). The same goes for other packages like geos, spatialite, rasterlite, spatialindex, postgis, etc, only one version will be included in the distribution that all reverse dependencies will use.<br>
<br>
Multiple versions make security updates more complex because more than one package needs to be patched, and also makes integration of reverse dependencies more complex because they'll need to be adapted for one of the versions.<br></blockquote><div><br></div><div>Ok, so the restriction is policy-based, not technical. Debian/Ubuntu releases won't provide multiple versions of GEOS, but if someone builds/runs their own repo then the system will support multiple versions (eg. continuing my example, a backport of the libgdal20 package will install alongside libgdal1h).</div><div><br></div><div>Seems fair enough :)</div><div><br></div><div>Followup question (and vaguely asking you to generalise on behalf of all distro maintainers) – do you think in the general case distros would take the upstream project advice and <i>not</i> set `--enable-the-cpp-sdk` in builds, and also therefore <i>not</i> accept uploads of new packages using the C++ API? Debian tends to have a build-with-the-kitchen-sink approach in my experience, but there has to be a limit somewhere.</div><div><br></div><div>Cheers</div><div><br></div><div>Rob :)</div><div><br></div></div></div></div>