transition to gcc/gnat-11

[Nicolas Boulenguez <nicolas@debian.org>]

Hello.

The transition to gnat-11 is on its way in experimental.
Mostly because of me, it has started quite late.

As usual, once all Ada packages build in experimental, we will request
the approval from FTPmasters, then reupload them to unstable.

There are unresolved issues, so I expect this to take a month or two,
but, as far as I know, nothing should prevent you from updating your
Ada package(s) for the experimental distribution.

Please report any problem to this list.
Of course, if you only need a sponsor for the upload, feel free to
contact a sponsor directly.

Thanks.

Hints for maintainers:

For debian/control/Standards-Versions, this link may be useful.
https://www.debian.org/doc/debian-policy/upgrading-checklist.html

For debian/rules, please use the unversioned debian_packaging.mk from
the gnat package instead of debian_packaging-$(GNAT_VERSION).mk from
the gnat-$(GNAT_VERSION) package.
The comments in the new version may be useful:
https://salsa.debian.org/debian/gnat/-/blob/master/debian_packaging.mk
Summary:
* include /usr/share/dpkg/buildflags.mk
* include /usr/share/dpkg/buildopts.mk
* include $(wildcard /usr/share/ada/debian_packaging.mk)
  (the call to wildcard is only required if you build
   architecture-independent packages and gnat is only present in
   Build-Depends-Arch.  If so, please add a comment explaining this)
  (you may remove the computation of GNAT_VERSION from debian/rules if
   include /usr/share/ada/debian_packaging-$(GNAT_VERSION).mk was the
   only reason for it)
* Replace BUILDER_OPTIONS with either GPRBUILDFLAGS or, more rarely,
  GNATMAKEFLAGS.
* (GPRBUILD|GNATMAKE)FLAGS includes -j$(DEB_BUILD_OPTION_PARALLEL),
  but, for example if you are using sphinx, you may need to add
  $(addprefix SPHINXOPTS=-j,$(DEB_BUILD_OPTION_PARALLEL)) to
  the override_dh_auto_build-indep recipe.

Thanks to Ludovic, I have realized that new GCC versions try not to
break the ABI compatibility.  This means that, unless there is another
reason, you do not need to change the SOVERSION in the shared library
package name.
Unfortunately, this seems to confuse some dependency resolvers, so a
local build may fail during the install-build-dependencies phase if an
old version of the library package is available.  If the only problem
you encounter is that you must update some Ada packages manually,
please ignore the issue. The automatic Debian builders use a smarter
dependency resolver anyway.
As usual, the ALIVERSION in the -dev package name must most probably
be updated.
For a details about ALI and SO versions:
https://people.debian.org/~lbrenta/debian-ada-policy.html