[prev in list] [next in list] [prev in thread] [next in thread] 

List:       debian-devel
Subject:    Re: 64-bit time_t: package lists, counts du jour, dd-list for NMUs
From:       Simon McVittie <smcv () debian ! org>
Date:       2024-01-22 14:55:51
Message-ID: Za6B94Lwa7k9lnlS () tautology ! pseudorandom ! co ! uk
[Download RAW message or body]

On Mon, 22 Jan 2024 at 05:31:45 -0800, Steve Langasek wrote:
> Others in this list have package names I don't understand, such as a 'd'
> suffix that doesn't correspond to anything in the soname

I believe this is conventionally used to mean "this is a Debian-specific
SONAME that intentionally differs from upstream's ABI", either because
the upstream project doesn't support building a shared library at all,
the upstream builds a shared library but breaks the ABI without bumping
the SONAME (and resists attempts to fix this upstream), or there is ABI
added/removed in Debian delta.

Ideally this would be addressed with an "upstream first" approach,
or failing that, it should genuinely be part of the SONAME, as in
e.g. libstemmer0d (which is static-only upstream, and Debian patches
the build system to produce a libstemmer.so.0d shared library) and
libleveldb1d (I haven't checked the history, but presumably it's similar).

For packages in the libstemmer0d situation, since the ABI is
Debian-specific *anyway*, the right route is perhaps to bump the SONAME
to libstemmer.so.0d1 or libstemmer.so.1d and handle it like a normal
transition?

Unfortunately, perhaps because common build systems like Autotools,
Meson and CMake make it awkward to use non-numeric SONAME suffixes,
there are also libraries that use the 0d suffix but *don't* include the
"d" in the SONAME, for example libcdd0d (libcdd.so.0).

Looking at the cddlib (libcdd0d) changelog, it seems that 0d is a little
misleading in this case, because the ABI is *not* Debian-specific:

   * Renamed libcdd0 to libcdd0d. The ABI changed since the last
     package, but upstream started using the SONAME 0 now. Since the
     package is not widely used, changing the package name, but not the
     SONAME, is enough.

For the libcdd0d situation, it's "the same shape" as a toolchain ABI
suffix like v5 or t64, so a rename to libcdd0t64 would probably be right
(if this package is affected by 64-bit time_t, which I haven't checked).

Another convention that is sometimes used if upstream doesn't really
handle ABI breaks the way we would want, and there is a manageably
small number of dependent packages in Debian, is to package the library
libfoo.so.0 as libfoo0, then libfoo0a, libfoo0b, and so on. This is
difficult to distinguish from the "0d" conventions above, if the ABI
happens to have been broken exactly 4 times. Examples of this include
libharfbuzz0b, libgjs0g, libcryptui0a.

Again, for the libharfbuzz0b case, it's "the same shape" as a toolchain
ABI suffix like v5 or t64, so a rename to libharfbuzz0t64 would probably
be right (if this package is affected by time_t at all).

> or libcoin80c

Unfortunately the changelog just says "Renamed package dropping v5 suffix
to c", without explaining why.

Since this used libcoin80v5 for the libstdc++ v5 transition, I would guess
that libcoin80t64 could be the right name for it now? But its maintainers
would know better.

    smcv

[prev in list] [next in list] [prev in thread] [next in thread]