Bug#1064378: libevolution: identified for time_t transition but no ABI in shlibs

[Michael Hudson-Doyle]

Package: libevolution
Version: 3.50.3-1
Severity: important
User: debian-arm at lists.debian.org
Usertags: time-t

Dear maintainers,

Analysis of the archive for the 64-bit time_t transition[0][1]
identifies libevolution 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 (also, a
quick manual peek at the headers suggests that the package very likely
to be affected by the transition!)

However, libevolution's shlibs file declares a dependency on a library
package name that contains no ABI information:

$ cat DEBIAN/shlibs
libeabutil 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libeabwidgets 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libecontacteditor 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libecontactlisteditor 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libecontactprint 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libemail-engine 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libessmime 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libevolution-addressbook-importers 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libevolution-calendar-importers 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libevolution-calendar 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libevolution-mail-composer 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libevolution-mail-formatter 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libevolution-mail-importers 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libevolution-mail 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libevolution-shell 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libevolution-smime 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libevolution-util 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libgnomecanvas 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
$

It is therefore not obvious that we should rename the package to
'libevolution-t64' as part of this transition.

Looking at the archive, the only packages that depend on this package
are also built from the evolution source package.

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 (e.g. upgrading
libevolution without also upgrading evolution-plugin-bogofilter) will
result in ABI skew and may result in broken behavior.

Cheers,
mwh

[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-02-16T21%3A19%3A00/logs/evolution-dev/base/log.txt


-- System Information:
Debian Release: trixie/sid
  APT prefers mantic-updates
  APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 'mantic'), (100, 'mantic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-17-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ.UTF-8:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled