[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

gnat-10 transition


The freeze for bullseye will start in december.
The default toolchain will be gcc-10.
gnat-10 is available, but not yet the default.

All Ada libraries must be updated for Gcc-10 and uploaded to
experimental.  Because of the new ALI and SO version, they will have
to pass through the NEW queue. Once the dust has settled in
experimental, all packages will be manually reuploaded to unstable,
then automatically migrate to testing.

AdaCore has released the GPL-2020 version of their tools.
https://www.adacore.com/download/more. This is a priori unrelated, but
dealing with this second transition at the same time avoids a second
passage through NEW.

The attached graph represents all Ada source packages.
  A box means that a single source builds several libraries.
  Green packages are ready for gcc-10.
  Red packages have critical problems, described below.
A normal arrow from A to B means that libB-dev depends on libA-dev.
  libB-dev must usually be renamed when libA-dev is renamed.
A dashed arrow from A to B means that the source for B mentions
  libA-dev as build, run or test dependency.  The source for B has to
  be trivially edited and rebuilt when libA-dev is renamed.

If you are maintaining a Debian library, please update it once its
dependencies are available in experimental, even if it only needs a
rebuild with new ALI and SO versions.


Some packages will probably not be part of bullseye.

* gnat-gps (Programming Studio) and gnatcoll-bindings-python are not
  ready for python3 yet.

  We may intend to keep the python2 versions available in unstable for
  interested users, in the hope that they can be reintroduced in the
  following release.
  A patch updating the library for python3 has been forwarded and
  applied upstream, so if anyone requires gnatcoll-python3 in
  bullseye, this could be worked out.
  On the other hand, GPS is broken in many other ways (for example,
  some functions are currently disable because libadalang misses).
  Help by someone actually using it would be welcome.


* The AdaCore GPL/2020 distribution does not include ASIS anymore.
  In the long term, this will affect at least adabrowse and
  adacontrol. For now, the GPL/2019 version seems to build fine with

* The AdaCore GPL/2020 distribution does not include gnatcoll-db anymore.
  Gnat-gps was the only known consumer, so this could probably be
  removed from Debian.

* AWS/2020 depends on libadalang instead of ASIS.

  Libadalang is not packaged for Debian (and similarly requires
  e3-core and langkit).

  For now, we intend to rebuild asis/19 and aws/19 as part of the
  current transition, but ideally someone would package libadalang and
  AWS/20 before the bullseye freeze.


Changes in specific packages.

* Changes in dh-ada-library may trivially affect reverse dependencies.

  The Linker'Linker_Options of the generated installed project were
  previously selected among (Leading_)Library_Options of the build
  project, and are now copied verbatim from Linker'Linker_Options.
  For each -lbar option, the related -dev package is added to ada:Depends.

  Maintainers of a 'foo' library using dh-ada-library, please:

  * check that the Linker'Linker_Options of the build project contains
    the appropriate -lbar options for an end user to link with libfoo.so.
    The default is empty, and is most probably the right value for
    pure Ada libraries.
    Options already listed by GNAT projects, either implicitly (like
    -lfoo) or implicitly (in imported Linker packages) need not be
    repeated here.
    Among Library_Options, only expected *direct* dependencies of the
    end user code are necessary (C imported functions are a common
    When in doubt, or when the list vary accross architectures, do not
    hesitate to append an item. This won't affect the end user now
    that --as-needed is enabled by default (except that ada:Depends
    may become larger than strictly necessary).

  * remove the related -dev explicit dependencies from the libfoo*-dev
    stanza of the control file. They should now be generated via
    ada:Depends.  This should only concern C dependencies, as Ada
    dependencies were already generated.

  * check that the generated project and Debian control file of the
    binary -dev package have not changed in unexpected ways.
    The following commands may help.
    # apt download libfooPREVIOUS-dev
    # debdiff libfooNEW-dev_*.deb libfooPREVIOUS-dev_*.deb
    # ar -p libfooPREVIOUS-dev_*.deb data.tar.xz | tar -JOx ./usr/share/gpr/foo.gpr | diff -u - debian/libfooNEW-dev/usr/share/gpr/foo.gpr

* If you use libgnatvsn:

  Gnatvsn is renamed to gnat_util.
  libgnat-util*-dev provides both gnat_util.gpr and a gnatvsn.gpr
  wrapper, so reverse dependencies should only need to update the
  Build-Depends field (this is already necessary because of the ALI

  * Debian's gnat-9, like its predecessors, used to build a
    Debian-specific libgnatvsn.
  * AdaCore GPL/2019 distribution has introduced libgnat_util,
    with almost the same contents, for ASIS and AWS.
  * Debians's gnat-10, gnatvsn has been renamed to gnat_util in
    order to reduce the divergence.
  * AdaCore GPL/2020 distribution removes gnat_util and ASIS.
    AWS uses libadalang instead.
  It is too late to revert the changes in gnat-10.

* If you use libgpr:

  gpr is renamed to gnatprj
  Like for gnatvsn, a compatibility gpr.gpr project is provided.

  * Debian's gnat-6, like its predecessors, used to build a
    Debian-specific libgnaprj.
  * Around gnat-7 and AdaCore GPL/2017, the sources have moved from
    gnat to gprbuild. The new name was libgnatprj.
    Debian has renamed libgnatprj to libgpr in order to reduce divergence.
  * Around 2018, it has appeared that another library had been using
    the three-letter name since long before 2017. The name had to
    change in Debian again.

* If you use libasis:

  Be warned that the AdaCore GPL/2020 distribution does not include
  ASIS anymore. For now, the GPL/2019 version seems to build fine with
  gnat-20, so Debian will package it.

* If you use libflorist:

  Since 2018, AdaCore GPL distributions do not contain Florist
  anymore.  Does anybody know if the package is maintained elsewhere?
  Does anybody use it?  Should it be removed from Debian?

Ludovic and Nicolas

Attachment: tmp.pdf
Description: Adobe PDF document

Reply to: