Package: android-libart Version: 14.0.0+r15-1 Severity: serious User: debian-...@lists.debian.org Usertags: time-t
Hi Jochen, Analysis of the archive for the 64-bit time_t transition[0][1] identifies android-libart as an affected package, on the basis that the headers could not be compiled and analyzed out of the box using abi-compliance-checker[2], so we have to assume it's affected. However, android-libart's shlibs file declares a dependency on a library package name that contains no ABI information: $ cat DEBIAN/shlibs libart 0 android-libart (>= 14.0.0+r15) libdexfile_external 0 android-libart (>= 14.0.0+r15) libdexfile_support 0 android-libart (>= 14.0.0+r15) libsigchain 0 android-libart (>= 14.0.0+r15) $ It is therefore not obvious that we should rename the package to 'android-libartt64' as part of this transition. Looking at the archive, there are packages that depend on this library, dexlist and dexdump. Despite being built from the same source package, they do not have a strict versioned dependency on android-libart but instead use the shlibs. Since there is no self-evident thing to do with the library package name here, we will not be handling this package as part of the mass NMUs. Instead I am filing a serious bug because partial upgrades from bookworm to trixie on 32-bit architectures (upgrading android-libart without also upgrading dex*) will result in ABI skew and may result in broken behavior. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org [0] https://wiki.debian.org/ReleaseGoals/64bit-time [1] https://lists.debian.org/debian-devel/2024/01/msg00041.html [2] https://adrien.dcln.fr/misc/armhf-time_t/2024-01-17/logs/android-libart/base/log.+txt
signature.asc
Description: PGP signature