luazlip: drop zlib library version check

[Flowdalic]

Found while preparing TeX Live 2023 packages for Gentoo, which today stabilized zlib 1.3:

Checking for the zlib library version breaks when zlib is updated to e.g., 1.3, as it causes

PANIC: unprotected error in call to Lua API (zlib library version does
not match - header: 1.2.13, library: 1.3)

However zlib never broke ABI. And such version checks are a common cause for breakage [1, 2]. Therefore, simply drop it.

1: madler/pigz#111
2: noxxi/p5-io-socket-ssl#137

Thanks-to: Sam James sam@gentoo.org

[kberry]

Checking for the zlib library version breaks when zlib is updated to e.g., 1.3, as it causes Thanks for the report and patch. However zlib never broke API. Then why isn't the new release 1.2.14 instead of 1.3? I thought the whole point of a change like 1.2.x -> 1.3.x was that new functions/interfaces were added, so there is an API difference, meaning a "breakage" if the new interfaces are used. And such version checks are a common cause for breakage [1, 2]. Agreed. PANIC: unprotected error in call to Lua API (zlib library version does not match - header: 1.2.13, library: 1.3) But why are the headers and the library different versions in the first place? That doesn't seem good. --thanks, karl.

[norbusan]

But why are the headers and the library different versions in the first place? That doesn't seem good.

Maybe the compilation of TeX Live was done using the zlib headers included in TeX Live instead of the system zlib headers, and then the system zlib library is used. That would explain the squeeze.

However zlib never broke ABI.

I disagree on that. I have seen years ago failures even due to point upgrades. It might be better now, though.

[norbusan]

To be specific, 10 years ago: https://lists.debian.org/debian-tex-maint/2010/06/msg00074.html

[norbusan]

And finally, Debian just added the following patch to relax the version check @kberry

https://github.com/debian-tex/texlive-bin/blob/master/debian/patches/untighten_version_check_zlib.diff

--- texlive-bin.orig/texk/web2c/luatexdir/luazlib/lzlib.c
+++ texlive-bin/texk/web2c/luatexdir/luazlib/lzlib.c
@@ -546,7 +546,7 @@
 
     /* make sure header and library version are consistent */
     const char* version = zlibVersion();
-    if (strncmp(version, ZLIB_VERSION, 4))
+    if (strncmp(version, ZLIB_VERSION, 2))
     {
         lua_pushfstring(L, "zlib library version does not match - header: %s, library: %s", ZLIB_VERSION, version);
         lua_error(L);

Probably something we should patch in TL, too.

[Flowdalic]

But why are the headers and the library different versions in the first place?

That is not an uncommon scenario for rolling release distributions like Gentoo.

However zlib never broke ABI.
I disagree on that.

Right, what I meant to say was that zlib did not break ABI in the last years.

Debian just added the following patch

We also considered this approach. And while it is not unlikely that a new major version release of zlib introduces some ABI breakage, it is also possible that it isn't the case. In the latter case, we end up with the same issue. We would need an upstream statement from zlib to clarify this. As far as I know zlib has not spelled out the semantics of their versioning (please correct me if I am wrong).

In any case, relaxing this check is sensible, considering the recent zlib 1.3 release.

[thesamesam]

To be specific, 10 years ago: lists.debian.org/debian-tex-maint/2010/06/msg00074.html

The discussion there seems to then talk about internals. "ABI" usually means public ABI, not private.

However zlib never broke API. Then why isn't the new release 1.2.14 instead of 1.3?

Unfortunately, not everybody uses a sensible version scheme like this :(

[kberry]

It seems sensible to me for TL to follow Debian here. I made that change (r68922). Thanks to all.

[Flowdalic]

r68922 made it as 7fb47ba into the git (mirror) of TeX Live's sources.

Thanks for addressing the issue.