> Jakub reported that for glibc 2.34 (trunk, unreleased), Richard said it was > working for glibc 2.33 (latest release), your commit says "Fix build > breakage with latest glibc release" (which is 2.33). What is correct?
Both I guess, mine is just a bit more forward-looking. ;-) > The symptom > "/usr/lib/x86_64-linux-gnu/ada/adalib/ahven/ahven-framework.ali" is obsolete > and read-only > looks exactly like the scenario described by the Debian Ada Policy. > https://people.debian.org/~lbrenta/debian-ada-policy.html > > Example with a simple dependency chain: > libahven depends on libgnat > ahven-tests depend on libahven > libahven contains, in ahven-framework.ali, a checksum of each source > it depends upon, including some libgnat sources. > When libgnat changes, libahven must be rebuilt before ahven-tests. > Else… > The error above is reported when building ahven-tests. > It mentions ahven-framework.ali from the libahven-dev package. > It actually originates in a change in libgnat. > > The Debian Ada policy requires that such dependencies are encoded in > -dev package names so that dpkg later automatically prevents > inconsistent sets of .ali files and related cryptic messages. > > In the special case of libgnat, built by GCC, there is only one > libgnatMAJOR package, containing the files usually expected in > libgnatSO and libgnatALI-dev. The sources are not expected to change > for a given MAJOR inside unstable. The change is supposed to be binary compatible so not sure what this means. > Assuming that the change is only required for glibc trunk (2.34), I'll > revert that for Debian's package builds for the gcc branches. I'll see what > to do if I still need gnat-10 when glibc 2.34 is in use. Otoh, the patch > could be conditional on the glibc version detected. Too much hassle. Please pester the glibc folks if you have any complaint. -- Eric Botcazou
