> > Hi Bas,
> 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. 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. > > > 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? Cheers, Jeremy
_______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
