For the second time, this discussion has become very passionate at some point. That being said, I believe all the package management issues being used as an excuse are more of an issue for Linux-based systems. Those who develop Linux-based applications should know better if they depend on system wide library distribution for their dependencies via some package management. For them, they should have stability in mind when doing their development. Why should a larger community pay for the poor choice of others and would have to jump through additional hoops to achieve what should be trivial in C++? I am not a Linux expert/developer and would not be in a position to judge. Such applications could consider static linking as alternative or risk being dropped by the PACKAGE MANAGERS and those who want to make their work easier. It is the responsibility of statically linked application to fix security updates. I do acknowledge most of the PSC/maintainers primary OS might be linux and might have their own preferences/biases.
GEOS, we should not forget has a considerable number of Windows users and on windows, each application is responsible for its own "sandbox" environment. A case in point is the layout of Postgis windows distribution as an example. If there is a required security update, it is handled at the individually installed application level and not system wide. People develop their own schemes to realize how their dependencies are met. I rarely hear such issues on Windows like package management. GEOS has the ability to gain more traction if such artificial restrictions are removed. Desktop application development stands to benefit a lot on windows - yes there are people out there using the library on windows. There is no gainsaying that those doing server application have other considerations to keep in mind. There should be nothing like "end of discussion - done" rather it should be based on facts/guidelines/practices as they are. Those who break it should pay the price. That said what, why should we prevent the C++ API for being used? Yes, it has special needs. I do not hear such arguments with GDAL. They broke the API and people had to fix their stuff did in order to use newer releases. The ABI issues as document should just be used as reference for those who complain. After all, GEOS is not LINUX kernel where such drastic considerations have their merits. Even LINUX, we have seen some positive transformations in the way Linux kernel is managed. Some people use mostly C language for the obvious reasons. Others use C++ and are looking forward to use the high level abstractions the new standards (11, 14, 17, 20x) are providing. The interests of the minority should be respected but should not be used as an excuse to stifle innovation. Yes there is Boost Geometry as an alternative but why has it not gained traction? Because of complexity - something GEOS has a an advantage. GEOS should not be used or turned into as Expert only library. Please remember package management is a long standing issue in C/C++ based on its characteristics - those being the same that make them popular when people want primarily performance. On Sat, May 18, 2019 at 12:23 AM Regina Obe <l...@pcorp.us> wrote: > Mat, > > I think you misunderstood me a little > > > The first and third statements in the second paragraph of your response > is false. > > I have ever asked to "guarantee a stable C++ API at this point in time" > or at any point ever. > > It's a fact. > > [Regina Obe] > > I never said you wanted to guarantee a stable C++ API. And we don't have > one is my point. > Something that is unstable should not be shared. It should be statically > linked or set aside for your own project and as such you shouldn't expect > package maintainers to carry your project. > > > > The second statement in the second paragraph of your response is also > false. > > GEOS users can and do depend on the C++ API. > > It's a fact. > No disagreement there - just don't want packagers burdened with having to > ship these projects and right now we have few if any that use the C++ API > that packagers need to ship. I'd like to keep it that way by discouraging > sharing of the C++ API. Installing headers etc -- as pramsey suggested > would just open up the flood-gates of C++ projects relying on the C++-API > until we have some REALLY IMPORTANT C++ project that relies on GEOS that > packagers would like to ship, and expecting them to statically link every > GEOS use is insane and a security hole. > > I care more about packagers feeling comfortable about shipping a newer > GEOS C-API and PostGIS being able to use a newer GEOS C-API than I feel > about making C++ developers happy. You people have all proven to be only > concerned about your self-interest and your toys. > > > > The arguments you present show to me you're pursuing goals of a package > manager but not a programmer who wrote that code. > > The way I see it Mat -- there are way more programmers than there are > packagers on the GEOS / PostGIS teams, so YES I got to look out for the > minority which has a major impact on the majority, because clearly no one > else seems to. > > > This brought incompatible toys in to the common sandbox. > What incompatible toys -- you still have your sandbox -- it's just a > little more sandboxed. > > > You do not want to recognize it. > I recognize it but I care much less about it than other things. You're > the one that turned in your keys to the GEOS project and said you didn't > want to be part of it anymore. I was extremely disappointed when you said > that. So why this sudden new found interest? > > > I'm not going to keep convincing you anymore. > Good cause we are in full agreement - we are just on opposite sides of the > spectrum. > > Thanks, > Regina > > > _______________________________________________ > geos-devel mailing list > firstname.lastname@example.org > https://lists.osgeo.org/mailman/listinfo/geos-devel
_______________________________________________ geos-devel mailing list email@example.com https://lists.osgeo.org/mailman/listinfo/geos-devel