Package: emboss-lib
Version: 6.6.0+dfsg-12
Severity: serious
User: debian-...@lists.debian.org
Usertags: time-t
Dear maintainers,
Analysis of the archive for the 64-bit time_t transition[0][1] identifies
emboss-lib 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, emboss-lib's shlibs file declares a dependency on a library package
name that contains no ABI information:
$ cat DEBIAN/shlibs
libacd 6 emboss-lib (>= 6.6.0+dfsg)
libajax 6 emboss-lib (>= 6.6.0+dfsg)
libajaxdb 6 emboss-lib (>= 6.6.0+dfsg)
libajaxg 6 emboss-lib (>= 6.6.0+dfsg)
libensembl 6 emboss-lib (>= 6.6.0+dfsg)
libepcre 7 emboss-lib (>= 6.6.0+dfsg)
libeplplot 3 emboss-lib (>= 6.6.0+dfsg)
libnucleus 6 emboss-lib (>= 6.6.0+dfsg)
$
It is therefore not obvious that we should rename the package to
'emboss-lib-64' as part of this transition.
Looking at the archive, there are packages built from separate source
packages which depend on these libraries: embassy-domainatrix,
embassy-domalign, embassy-domsearch.
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 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/emboss-lib/base/log.txt
signature.asc
Description: PGP signature
