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

[Nicolas Boulenguez]

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