• Re: [Summary]: Supporting alternative zlib implementations

    From Fay Stegerman@21:1/5 to All on Sun Nov 24 02:10:01 2024
    * Chris Hofstaedtler <zeha@debian.org> [2024-11-23 20:56]:
    * Fay Stegerman <flx@obfusk.net> [241123 19:58]:
    I agree that it *should not* be Debian's responsibility to ensure compatibility
    with Fedora/Windows/etc., but the reality is that if "you need the same tools to
    generate the same output" -- which right now means using the same JDK and Android toolchain but in 99% of cases doesn't require using the same OS since
    everyone, including Google [2], standardised on zlib -- becomes "you cannot reproduce APKs built on a OS other than Debian on Debian", that's not just "annoying for the involved parties": it will effectively break the ability to
    verify reproducibility of many Android apps.

    Sorry, but what exactly are you saying here? That Debian should be
    bound by the decision of a BigTech Corporate and by thousands of
    individual Android developers, neither of which might be interested
    in Debian?

    To maybe make the argument the other way 'round: if Google switches
    to zlib-ng tomorrow, should Debian be required to switch to zlib-ng?

    What I'm saying is that this change will have consequences for downstreams using
    Debian for Reproducible Builds. That includes e.g. hundreds of F-Droid apps, which would no longer be able to get updates if Reproducible Builds break.

    That's clearly not Debian's fault. And of course Debian isn't *required* to do anything. I agree Debian should not be bound by the decisions of a "BigTech Corporate" and thousands of individual Android developers. And I very much dislike the fact that this matters.

    But Debian's choices here do have consequences for downstreams, and I think that's something we should take into account when reasonably possible. Similar to how we didn't switch i386 to t64 to avoid breaking running existing legacy binaries.

    For example, if it can be made easy to install both and choose between zlib and zlib-ng at runtime, so it's easy to build APKs using either zlib or zlib-ng as needed, downstream breakage can be avoided. Considering whether that can reasonably be done doesn't seem like an unreasonable request to me.

    What I would like is to be able to continue to use Debian for Reproducible Builds regardless of what Google does or doesn't do. Right now that means being
    able to choose to keep using the original zlib for backwards compatibility. If Google switched to zlib-ng I would be asking if Debian could provide a way to opt in to using that instead.

    - Fay

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bill Allombert@21:1/5 to All on Sun Nov 24 22:40:01 2024
    Le Fri, Nov 22, 2024 at 12:56:17PM +0000, Simon McVittie a écrit :
    Switching .... from IJG
    libjpeg to libjpeg-turbo, both went through similar processes.

    Independently of the merit of your proposal, this is not historically
    correct.

    Cheers,
    --
    Bill. <ballombe@debian.org>

    Imagine a large red swirl here.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mark Brown@21:1/5 to Fay Stegerman on Fri Dec 6 18:20:01 2024
    On Sun, Nov 24, 2024 at 02:06:37AM +0100, Fay Stegerman wrote:

    For example, if it can be made easy to install both and choose between zlib and
    zlib-ng at runtime, so it's easy to build APKs using either zlib or zlib-ng as
    needed, downstream breakage can be avoided. Considering whether that can reasonably be done doesn't seem like an unreasonable request to me.

    What I would like is to be able to continue to use Debian for Reproducible Builds regardless of what Google does or doesn't do. Right now that means being
    able to choose to keep using the original zlib for backwards compatibility. If
    Google switched to zlib-ng I would be asking if Debian could provide a way to opt in to using that instead.

    TBH the whole situation here seems incredibly fragile - you're also
    vulnerable to someone making an improvement in the zlib compression
    code and changing the generated output that way. It feels like the
    wrong question is being asked here.

    -----BEGIN PGP SIGNATURE-----

    iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmdTLdUACgkQJNaLcl1U h9Dqdgf9ELjBpCUtdDkm8F/q9OuCJm5dsplPPPwh0Itzr29gx0DTotGfV+fXDdWu iJqO+hHDKIoS7mqXa2vPKMrNd4x5K5rhd7mI1imlA/ey42yEopOIs9SnEs8p1UCz yu47HjAAFu7nuVMRiphAgpgTLQedseRwIgaHsn6PDQp8xXqDrmQhRM4m5qOan7p/ nfIEoUbiObU2GGK/JDTY+tpqwnopWMu2g4WeLg2ThZVSWhDVsdbIPyKFjXB/rFGS TIPb42mn2MDH+W52zqBgN+QoR8zYkj3jZgqq5CM6+djykXRZPP7pDZ63Muv3n6Xt 8PbnVsoonitCOR0NPxiy8wbW1h5UUQ==
    =ffpQ
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)