Thanks for your detailed reply, Nicolas.
I must admit that my knowledge of ADA is almost inexistant. I even do
not knew what ALI means, until I looked at the documentation.
I do not have time to plunge deeper into this issue now. I have already
committed all the patches that you submitted in the presetn bug report
[1–8]. I will make a new release to unstable containing this changes,
because I think that they improve the Debian packaging.
I will then apply the patch that changes libplplotada1 ⇒ 2 and upload the
new version to experimental, as you suggested.
Best,
Rafael
[1] https://salsa.debian.org/science-team/plplot/commit/8e1f9be7 Improve
transmission of configuration variables
[2] https://salsa.debian.org/science-team/plplot/commit/b23103c8 Compile Ada
with hardening flags
[3] https://salsa.debian.org/science-team/plplot/commit/1cec9ebc Enable all
linker checks
[4] https://salsa.debian.org/science-team/plplot/commit/bd0d7e5c Import
specific dpkg makefile snippets instead of default.mk
[5] https://salsa.debian.org/science-team/plplot/commit/27a1a2b0 Drop HOME
unused variable from debian/rules
[6] https://salsa.debian.org/science-team/plplot/commit/f93b7cb6 Remove the
workaround preventing compression of examples
[7] https://salsa.debian.org/science-team/plplot/commit/410c23ab Delegate
temporary directory to autopkgtests
[8] https://salsa.debian.org/science-team/plplot/commit/365cd6cc Drop an
explicit dependency in tests/control
* Nicolas Boulenguez <nico...@debian.org> [2019-12-09 21:49]:
I ignore if this compiler change breaks the plplot-ada ABI. If so,
libplplotada4.deb should be renamed to libplplotada5.deb, and CMake
should be told that plplotada_SOVERSION=5.
Could you please suggest a way to test for the ABI breakage ?
The new compiler may implement the same high-level structure with a
new bit construct, or change the calling convention, or…
I am not sure how to check this.
However, the Ada libraries almost always require an ALI bump (see
below) when the libgnat sources are modfied, so I tend to stay on the
safe side and increment the SO too, unless GCC guarantees that the ABI
of the previous major release is preserved (I've only seen this once).
At any rate, I think that bumping the SOVERSION like this must be done
upstream, don't you think? I am not sure it is a good idea to have the
Debian packaging messing with this.
It is always possible that a security update requires a change in the
profile of an existing function (or the implementation), so there is
no way to avoid divergence of the SOversion (or the ALIversion) in
general. I try to keep the ordering compatible with upstream
SOversions, at least when upstream manages the SOversions.
I have also another question regarding the package naming. I see that you
introduced, in commit 95d5fc9 [1], the change in naming of libplplot-ada-dev
to libplplotada1-dev. Is there any specific reason you have chosen the
number "1"? Would it not be better to have both packages in sync, like
libplplotadaN and libplplotadaN-dev?
This is explained in the Debian policy for Ada [1]. The SO version (in
the library package name) and the ALI version (in the -dev package
name, specific to the Debian packaging) have no reason to be in sync,
allthough practically we try to update both at the same time when
possible to spare a passage through the NEW queue.
[1]
https://people.debian.org/~lbrenta/debian-ada-policy.html#No-coexistence-allowed
