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