Re: Supporting alternative zlib implementations
On Wed, Sep 25, 2024 at 01:55:17AM +0200, Guillem Jover wrote:
> Hi!
>
> On Wed, 2024-09-25 at 00:39:10 +0200, Fay Stegerman wrote:
> > * Guillem Jover <guillem@debian.org> [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.
As someone who recently tested a rust port of zlib-ng, another factor to
take into account is that while zlib-ng is faster, it also looks like it
compresses less at the same compression level.
Using higher compression levels with the same compression rate is also
usually faster too, but without touching the compression levels, you
end up with something that compresses in less time, but also with a
bigger output.
Mike
Reply to: