On Tue, Oct 03, 2017 at 08:15:05PM -0400, Greg Troxel wrote: > 3) do I reimport the geos package as geos35 and namespace it to allow > simultaneous installation with the 3.6 version, and have some way for > osm2pgsql to link against the 3.5 version instead.
The C++ geos library should already have a different name for every version (both filename and SONAME). But I guess you'd need to tweak the link line of depending packages to find the correct one ? > Is it a geos bug that the C++ API changes in ways that break programs > that use it? I wouldn't say so. It's documented that the C++ API is subject to frequent changes. In the future I see more smart pointers and templates coming, which would be again destruptive for the C++ API (but safe for the C API). > Is it a bug for other programs to use the C++ API at all? It's not a bug per-se, but it introduces some issues for packagere. > programs shouldn't really use the C++ API. But if they do, they have > to cope with changes, because we aren't making stability guarantees. > So packagers should feel free to update geos to a release with an > API-breaking change after a few months, and if any depending package > breaks, it's their fault because they should have had a new release > that can use the new API. Had you consider NOT replacing one version of GEOS C++ library with another but rather keep both, when one of the packages doesn't build (or work, ABI-wise) with new version ? --strk; _______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
