<div dir="ltr"><div><div><br></div><div>> It is not the library's responsibility to provide personal protective equipment. </div><div>> C++ users know the deal and accept that bargain when they use APIs</div></div><div><br></div><div><div>With my packagers hat on... just offering a data point about what exists that many folks might not know about.</div><div><br></div><div><div>If we can add a flag to the build configuration to keep the C++ install, then life will continue as normal for users of fink.  I'll leave the evaluation of the quality of the solution to others, but it has kept fink packaging going with GEOS.</div></div><div><br></div><div>BABA and I have been packaging GEOS for fink on the mac for a long time now.  We have created a tree that has separate contained areas for each release of geos.  Only one -dev package can be installed at a time and and subtree depending on geos must stick to the same version of geos.  Those building their own stuff against geos can go it alone with an older version of geos.  We don't even expose anything in the global /sw/{bin,lib,include}.  headers, libs, and geos-config are down in the version directory so that people have to buy into it.</div><div><br></div><div>I've not done the same with GDAL.  You buy into one version of GDAL and that what you are forced to.  ABI problems in external code using GDAL from fink?  My only response is: recompile and fix anything that doesn't match the current API.</div><div><br></div></div><div><div>fink list libgeos</div><div>Information about 11072 packages read in 1 seconds.</div><div>     libgeos3.3.0                              3.3.0-1                         Geometry Engine - Open Source</div><div>     libgeos3.3.0-shlibs                       3.3.0-1                         Geometry Engine - Open Source</div><div>     libgeos3.3.1                              3.3.1-1                         Geometry Engine - Open Source</div><div>     libgeos3.3.1-shlibs                       3.3.1-1                         Geometry Engine - Open Source</div><div>     libgeos3.3.3                              3.3.3-1                         Geometry Engine - Open Source</div><div>     libgeos3.3.3-shlibs                       3.3.3-1                         Geometry Engine - Open Source</div><div>     libgeos3.3.6                              3.3.6-1                         Geometry Engine - Open Source</div><div>     libgeos3.3.6-shlibs                       3.3.6-1                         Geometry Engine - Open Source</div><div>     libgeos3.3.8                              3.3.8-1                         Geometry Engine - Open Source</div><div>     libgeos3.3.8-shlibs                       3.3.8-1                         Geometry Engine - Open Source</div><div>     libgeos3.4.2                              3.4.2-1                         Geometry Engine - Open Source</div><div>     libgeos3.4.2-shlibs                       3.4.2-1                         Geometry Engine - Open Source</div><div> i   libgeos3.5.0                              3.5.0-2                         Geometry Engine - Open Source</div><div> i   libgeos3.5.0-shlibs                       3.5.0-2                         Geometry Engine - Open Source</div><div> i   libgeos3.6.1                              3.6.1-1                         Geometry Engine - Open Source</div><div> i   libgeos3.6.1-shlibs                       3.6.1-1                         Geometry Engine - Open Source</div></div><div><br></div><div><div>dpkg -L libgeos3.6.1-shlibs | egrep '[.](dylib|a)'</div><div>/sw/opt/libgeos3.6.1/lib/libgeos-3.6.1.dylib</div><div>/sw/opt/libgeos3.6.1/lib/libgeos_c.1.dylib</div></div><div><br></div><div><div>dpkg -L libgeos3.6.1 | egrep '[.](dylib|a)'</div><div>/sw/opt/libgeos3.6.1/lib/libgeos.a</div><div>/sw/opt/libgeos3.6.1/lib/libgeos_c.a</div><div>/sw/opt/libgeos3.6.1/lib/libgeos.dylib</div><div>/sw/opt/libgeos3.6.1/lib/libgeos_c.dylib</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 4, 2017 at 8:19 AM, Howard Butler <span dir="ltr"><<a href="mailto:howard@hobu.co" target="_blank">howard@hobu.co</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><br><div><blockquote type="cite"><div>On Oct 4, 2017, at 12:08 AM, Regina Obe <<a href="mailto:lr@pcorp.us" target="_blank">lr@pcorp.us</a>> wrote:</div><br class="m_8655283915458917743Apple-interchange-newline"><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">According to RFC1 – it says the motion can not pass    <a href="https://trac.osgeo.org/geos/wiki/RFC1" style="color:purple;text-decoration:underline" target="_blank">https://trac.osgeo.org/<wbr>geos/wiki/RFC1</a>  with a -1 and I have to give Hobu a chance to debate his point<span class="m_8655283915458917743Apple-converted-space"> </span></span><span style="font-size:11pt;font-family:Wingdings;color:rgb(31,73,125)">J</span><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><b>"Respondents may vote "-1" to veto a proposal, but must provide clear reasoning and alternate approaches to resolving the problem within the two days."<u></u><u></u></b></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">So I'd like to hear Hobu's alternative suggestions.</div></div></blockquote></div><br></span><div>Sandro's suggestion to require users to #define an obnoxious acknowledgement to use the C++ API, with the expectation that it continues to be installed by default for any and all to continue, is a reasonable compromise to me.</div><div><br></div><div>I'll back down my -1 to -0 if the RFC is modified to reflect that scenario.</div><div><br></div><div><blockquote type="cite"><span style="font-family:'Times New Roman',serif;font-size:16px">Thanks for picking up this issue, and your persistence and pragmatism, and the way you strived to listen to concerns and reach a consensus. Frankly from reading all the threads in one sitting, Mateusz and Howard didn't approach it similarly which is disappointing.</span></blockquote><br></div><div>My pragmatism is we don't get to change the rules after we've put things out there and people now might depend upon us. The C++ API for GEOS *pre-dates* the C API. The GEOS C API was a response to the recognition that some API insulation (along with a FFI-friendly interface) would be useful. </div><div><br></div><div>It is not the library's responsibility to provide personal protective equipment. C++ users know the deal and accept that bargain when they use APIs. My note about GDAL in the previous email was to acknowledge that this same suggestion, to remove the C++ API, could not even be seriously considered there because there is so much public use of that API. There's even more *private* use that people probably don't know about. The same could be said for GEOS.</div><div><br></div><div>Packaging systems need to make decisions about moving forward with base versions of foundational libraries like GDAL and GEOS with acknowledgement that doing so may cause some laggards to be dropped. The packagers can't write software to update the laggards, and the libraries need the freedom to innovate. Attention is life, as Paul said.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Howard</div><div><br></div><div><br></div></font></span></div><br>______________________________<wbr>_________________<br>
geos-devel mailing list<br>
<a href="mailto:geos-devel@lists.osgeo.org">geos-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/geos-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/geos-devel</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--<div><a href="http://schwehr.org" target="_blank">http://schwehr.org</a></div></div>
</div>