Subject: Bug#1002056: Supporting alternative zlib implementations

From: Guillem Jover <[email-masked]>
Date: Wed, 25 Sep 2024 01:55:17 +0200

Hi!

On Wed, 2024-09-25 at 00:39:10 +0200, Fay Stegerman wrote:
> * Guillem Jover <[email-masked]> [2024-09-24 17:45]:
> > Personally, I think fully migrating from zlib to zlib-ng would sound
> > great (even for trixie), but I guess we can take it slow if you do not
> > feel confident or have concerns over this.
> 
> As using an alternative zlib implementation could impact Reproducible Builds
> [1], I would recommend taking that into consideration before deciding on this
> kind of change.

Ah, this is related to something I wanted to mention too and forgot.

I don't think the specific case you mention is in itself a concern for
Debian, because we only guarantee reproducibility given the same inputs,
which includes the set of packages and their versions that were used
when building the binaries. So if there was a switch, those would end up
being recorded as well, and used when reproducing the outputs. And this
could also happen with a newer version of zlib itself.

The problem though is, that because the compressed stream is going to
change, that can make certain test suites fail if we perform this
switch, which I think would be the main fallout that we'd see from
this and would need manual fixing, although I assume Fedora has probably
handled most of these already. For example when I added explicit
zlib-ng support to dpkg, I had to fix its test suite to parametrize
sizes for test artifacts.

I think it would be pretty easy to at least see the extent of this
fallout by performing a mass rebuild for packages build-depending
on zlib1g-dev with a zlib-ng version.

Thanks,
Guillem