#1061729 libclips: identified for time_t transition but no ABI in shlibs

Package:
libclips
Source:
libclips
Description:
CLIPS shared libraries
Submitter:
Steve Langasek
Date:
2025-08-11 15:23:44 UTC
Severity:
normal
Tags:
#1061729#5
Date:
2024-01-29 08:21:25 UTC
From:
To:
Package: libclips
Version: 6.30-4.1
Severity: serious
User: debian-arm@lists.debian.org
Usertags: time-t

Hi Javier,

Analysis of the archive for the 64-bit time_t transition[0][1] identifies
libclips 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, libclips's shlibs file declares a dependency on a library package
name that contains no ABI information:

$ cat DEBIAN/shlibs
libclips 6 libclips (>=6.21-1)
$

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

Looking at the archive, there is a package that depend on this library,
clips.  Despite being built from the same source package, it does not have a
strict versioned dependency on libclips but instead uses 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 libclips without also upgrading
clips) will result in ABI skew and may result in broken behavior.

Thanks,