Bug#946400: plplot: please build the Ada binding with gnat-9

[Rafael Laboissière]

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 <nicolas at 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
>