Bug#1024179: zlib breaks libcompress-raw-zlib-perl autopkgtest: 02zlib.t fails

[Niko Tyni]

Control: reassign -1 libcompress-raw-zlib-perl 2.202-1

On Tue, Nov 15, 2022 at 09:56:57PM +0100, Paul Gevers wrote:
> Source: zlib, libcompress-raw-zlib-perl
> Control: found -1 zlib/1:1.2.13.dfsg-1
> Control: found -1 libcompress-raw-zlib-perl/2.202-1
> Severity: serious
> Tags: sid bookworm
> User: debian-ci at lists.debian.org
> Usertags: breaks needs-update

Thanks for the report.

> #     Failed test (t/02zlib.t at line 532)
> #          got: 1
> #     expected: -3

It looks like this is a (possibly test-only) problem in
libcompress-raw-zlib-perl.

>From the log:

   not ok 2 - ZLIB_VERSION (1.2.11) matches Compress::Raw::Zlib::zlib_version
   #     Failed test (t/compress/CompTestUtils.pm at line 61)
   #          got: '1.2.11'
   #     expected: '1.2.13'
   # 
   # The version of zlib.h does not match the version of libz
   # 
   # You have zlib.h version 1.2.11
   #      and libz   version 1.2.13
   # 
   # You probably have two versions of zlib installed on your system.
   # Try removing the one you don't want to use and rebuild.
   
This is failing just because the runtime zlib version is not the same
that the package was built with.

   not ok 126
   #     Failed test (t/02zlib.t at line 498)
   #          got: 1
   #     expected: -3
   [...]
   not ok 134
   #     Failed test (t/02zlib.t at line 532)
   #          got: 1
   #     expected: -3
   
These two trip on the same thing: apparently there's been a behaviour
change in zlib 1.2.12. The test file has been adjusted for the change
and has this comment:

  # Z_STREAM_END returned by 1.12.2, Z_DATA_ERROR for older zlib

but it's choosing the expected behaviour based on the build time zlib
version rather than the runtime one.

Not sure how to fix these issues best. Ideally the package would not
bake the build time zlib version in the binary, but it's probably part
of the interface now . The documentation says all the zlib constants
are automatically imported and I suppose that includes ZLIB_VERSION.

I doubt the version skew causes any real problems but we can't really
be sure about that. Applications could be choosing their behaviour based
on ZLIB_VERSION. So just disarming the failing tests during autopkgtest
and allowing version skew runs seems a bit risky.

The obvious alternative is to play it safe and add tight versioned
dependencies on the zlib1g package, requiring rebuilds whenever there's
a new zlib upstream version. That seems overkill to me.

Note that if we do introduce the tight dependencies, src:perl has a
separate copy of Compress-Raw-Zlib which should probably get the same
treatment.
-- 
Niko Tyni   ntyni at debian.org