<div dir="ltr">Hi Bas,<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 12, 2018 at 8:54 AM, Sebastiaan 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
</div></div>When you need newer versions of the core geospatial libraries like GEOS<br>
& GDAL than what is provided in the Ubuntu LTS releases, you'll need<br>
some 3rd party repository because Ubuntu doesn't provide backports. The<br>
geospatial packages in Ubuntu are actually not actively maintained at<br>
all, active maintenance only happens in Debian and Ubuntu just copies<br>
its packages from Debian.<br></blockquote><div><br></div><div>But I assume Ubuntu <span style="color:rgb(51,51,51);font-family:"Ubuntu Beta",UbuntuBeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;font-size:13px">universe and multiverse packages could be better maintained if someone stepped up to do it.</span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The nature of LTS releases is that they don't change the versions of the<br>
packages they provide, Debian stable, Ubuntu LTS and RedHat/CentOS don't<br>
differ much in the respect.<br>
<br>
When the users of those distributions do have a need for newer packages<br>
they need to get backports somehow, either through some 3rd party<br>
repository over which they have no control, or their own in-house<br>
repository which they do control. The latter is the best option to<br>
prevent any surprises when the repository gets new versions, it does<br>
require integration work to rebuild all related packages to work with<br>
the new versions of the libraries in question.<br>
<span class="gmail-"><br>
> I'm not sure if this problem is something that can be done by OSGEO or some<br>
> other alliance of companies. My feeling is no one company can currently<br>
> provide this service as it requires expertise across the full stack, or<br>
> enough scale in business to centralise support for the whole stack.<br>
<br>
</span>As long as the geospatial packages in Debian and UbuntuGIS are<br>
maintained by volunteers the users of those packages can't expect more<br>
than work on a best effort basis. No one is employed to maintain these<br>
packages for the wider community, although there seems to be a need at<br>
least for corporate Ubuntu users. Mapgears sponsored work on UbuntuGIS<br>
in the past, but that was apparently not successful enough to continue. </blockquote><div> </div><div>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.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">One of the benefits of open source is that companies are not dependent </span> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">on suppliers, and can employ people to the needed work in-house.</span></blockquote><div><br></div><div>In regards to not being locked into companies, I don't see that providing more robust community packaging is going to change this siutation.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px"> This</span> <span style="font-size:12.8px">work can be shared with the community, but generally corporate needs</span> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">differ quite a bit from community needs and</span></blockquote><div><br></div><div>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. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px"> its cheaper to just keep it </span><span style="font-size:12.8px">all in-house.</span></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
</span>I don't understand the question.<br>
<br>
The version requirement in the dependencies reflect the minimum version<br>
the code in the dependent package requires to work with the library.<br>
Some parts of qgis use features introduced in GDAL 2.x whereas other<br>
parts don't use features introduced after GDAL 1.8.0. Because the<br>
various parts of qgis are split into separate packages you get the<br>
different version requirement for gdal for those parts.<br>
<br>
There is generally only a single gdal package in the repositories like<br>
in Debian and Ubuntu. Only when one adds a 3rd party repository like<br>
UbuntuGIS is another version of the gdal package available, and you get<br>
integration issues like qgis being uninstallable with the UbuntuGIS<br>
dependencies after gdal is updated there but qgis hasn't been rebuilt<br>
with the new version yet.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>Jeremy</div><div> </div></div></div></div>