• libgeos++-dev intentionally broken

    From Enrico Zini@21:1/5 to All on Mon Sep 12 14:10:01 2022
    Hello,

    GEOS upstream[1] explicitly offers a C++ API, with no API stability
    across different versions, and a C API, as a stable wrapper to the C++
    API with API and API stability guarantees.

    The Debian libgeos++-dev package has intentionally stopped[2] shipping
    some include files that are needed to build programs with the C++ API,
    stating:

    The files are explicitly removed because the C++ API should not be used
    by others.

    Having to rebuild rdeps for every upstream release is unacceptable.

    This[3] is the corresponding issue in Ubuntu.

    I do understand that Debian is not a good match for a C++ library that
    does not make API and ABI stability guarantees, but the current solution declares that the package exists but breaks builds, not just of Debian
    packages using it, but also of software not shipped in Debian[4].

    I wonder if there can be a better way of stating lack of support for
    packages in Debian built using the C++ API, than the current situation
    of shipping a broken package. Even now having libgeos++-dev in Debian,
    shipping only the C API, would be better than a broken version.

    Ideas for alternative approaches, that would still honor the desire of
    the maintainer of not having to deal with the ripple effects of API/ABI changes?


    Enrico

    [1] https://libgeos.org/
    [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010002#20
    [3] https://bugs.launchpad.net/ubuntu/+source/geos/+bug/1980147
    [4] https://github.com/ARPA-SIMC/arkimet/issues/291
    --
    GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enrico@enricozini.org>

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCAAdFiEEJJAhGtA2CH5tHZqS0P9Jy+P0+2gFAmMfH6YACgkQ0P9Jy+P0 +2i9Xg/8CAOb9CYDUKGzVmeQ9eMvaJg3lBAU8/IQ5DI0p1n0l5MyYwWPChiBsRwe a58NTB3IA1iinJlXCeTn4OiA8CSiceq0bOFMgEv6ClMsJFc1d9omatBff6OACZfL kbaTnZ35uskcdlRVd/L5JJZpY0O/qVnXMfh+W1FhO4NEJ1KHtKvWOo0ZYE46jsZS z3YAmdiOZvZHZtQAhjnIq+h82QoOpmh2zLjjMeeljB100eKlCaPEdyetlox6o12V 4YN9u1aTlcm9+ZZEXWljFNHntppqMhDb4Q8TXCSMDIv7k9Fu+o4JEJczsnWtlgO0 UmkmVzlYybFgKZvfMO7NpGE2ZbMUqArRO6+Yw48lbZXiOm5zhdHTtKMv6FldVTST tH4plhvwF7SIXJwP0AXFYNGlKOgrVxMFM4YbVB8+h/q+usRm6aaWXv+RU6xQq9BI YZ2n5sT8sKYQZpVj1r9fC/oTLTqhYHq+2Rh4sE8aSf/uy0VVYa12c7dYmsZ+rmpX 31OX/bMP1RP59jlCL/d7pggFbRBbIrLPZnXmtfZ3PJMxQe9BCN3l9xktunkFAcN2 8UgTrRYoOe78BBvhZ1uE9FNG102v+ly/1k5VYZyUqqfwnS7338wp6u35rh36mEO+ zrYUiFSPkb5hChsqrAUdRQHk3CuY7XsWoOc9rtWENrBY2cEigbQ=
    =Ze17
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sebastiaan Couwenberg@21:1/5 to Enrico Zini on Mon Sep 12 14:20:01 2022
    On 9/12/22 14:01, Enrico Zini wrote:
    The Debian libgeos++-dev package has intentionally stopped[2] shipping
    some include files that are needed to build programs with the C++ API, stating:

    Upstream removed the .inl files in 3.11.0:

    https://github.com/libgeos/geos/blob/3.11.0/NEWS.md?plain=1#L22

    Kind Regards,

    Bas

    --
    GPG Key ID: 4096R/6750F10AE88D4AF1
    Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Lisandro_Dami=C3=A1n_Nica@21:1/5 to Enrico Zini on Mon Sep 12 14:20:01 2022
    Hi,

    On Mon, 12 Sept 2022 at 09:02, Enrico Zini <enrico@enricozini.org> wrote:

    Hello,

    GEOS upstream[1] explicitly offers a C++ API, with no API stability
    across different versions, and a C API, as a stable wrapper to the C++
    API with API and API stability guarantees.

    The Debian libgeos++-dev package has intentionally stopped[2] shipping
    some include files that are needed to build programs with the C++ API, stating:

    The files are explicitly removed because the C++ API should not be used
    by others.

    Having to rebuild rdeps for every upstream release is unacceptable.

    This[3] is the corresponding issue in Ubuntu.

    I do understand that Debian is not a good match for a C++ library that
    does not make API and ABI stability guarantees, but the current solution declares that the package exists but breaks builds, not just of Debian packages using it, but also of software not shipped in Debian[4].

    I wonder if there can be a better way of stating lack of support for
    packages in Debian built using the C++ API, than the current situation
    of shipping a broken package. Even now having libgeos++-dev in Debian, shipping only the C API, would be better than a broken version.

    Ideas for alternative approaches, that would still honor the desire of
    the maintainer of not having to deal with the ripple effects of API/ABI changes?

    There is no other option I know of. In this case not shipping the C++
    headers is the right thing to do, in my point of view.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)