On Fri, 22 Nov 2024 at 12:29:51 +0100, Guillem Jover wrote:
> depending on the outcome of this discussion, I think other
> (probably better) options would be to perhaps name the compat packages
> something like libz-ng-compat*, or drop them completely?
You might find the history of the sdl12-compat source package interesting.
It's a reimplementation of the SDL 1.2 API/ABI in terms of SDL 2, and it
went through several stages:
- only SDL 2 available (as of bullseye);
- sdl12-compat available as non-default and outside the normal library
search path, but can take over from "classic" SDL 1.2 if explicitly
requested via LD_LIBRARY_PATH or by installing a extra "shim" package
(this state is what we shipped in bookworm);
- sdl12-compat takes over binary packages from "classic" SDL 1.2,
"classic" SDL 1.2 disappears, sdl12-compat's old binary packages become
transitional (this is the current state in trixie);
- in forky, we'll presumably drop the transitional packages
Having the second step made it a lot easier to check for regressions.
Switching from glibc's libcrypt to the external libxcrypt, and from IJG
libjpeg to libjpeg-turbo, both went through similar processes.
sdl12-compat is a bit different because it's *only* the
backwards-compatible API/ABI, and not the "native" API/ABI (but you could
think of libsdl2, in its own source package, as being the corresponding
"native" API/ABI).
libxcrypt has a "native" legacy-free API/ABI available, but in Debian we don't
seem to be compiling it at the moment, and we only have the glibc- and
musl-compatible backwards-compatible ABIs (but I think some other distros
like Arch have moved to the legacy-free ABI).
libjpeg-turbo has a "native" legacy-free API/ABI libturbojpeg* in parallel
with a backwards-compatible API/ABI resembling IJG libjpeg 6b, so in that
sense it seems the closest to what you're proposing for zlib-ng.
> * I've had concerns [...] about providing the zlib compat API and the
> native zlib-ng API in sid, and then getting a mess of packages
> linking against (true) zlib and against (native) zlib-ng
Is there any problem with that, other than duplicate functionality?
>From the other things you've said about the native API, it sound as
though the symbols all have different names, so this is no worse than
the duplication you would get if you have indirect dependencies on both
zlib and libdeflate, or on both OpenSSL and GNUTLS; it isn't like trying
to link to both libreadline and libedit (which export essentially the
same symbols and so will collide badly), or more than one of GTK 2/3/4
(likewise).
smcv
