zlib-ng strategy -- drop in for zlib vs side by side installation

[hmaarrfk]

Your question:

We've been discussing conda-forge/zlib-ng-feedstock#10 (comment) making zlib-ng a potential drop-in for zlib.

@jaimergp mentionned

Some other references for similar conversations in other distros:

• ArchLinux: done
• adopt zlib-ng as a replacement for zlib bottlerocket-os/bottlerocket-core-kit#392: done
• [Package Request] - zlib-ng-compat and all related zlib-ng enhancements for core OS, from Fedora 40/CentOS 10/Redhat 10 amazonlinux/amazon-linux-2023#872: in discussion
  . - Debian: in discussion

OpenSuSE seems to be using it too? (I had to click on "Required by"). dotnet/runtime#101465

personally, I think that each individual package should opt-in to using zlib-ng instead of changing zlib as a whole.

However, there seems to be a strong push by many that this might be the wrong strategy given the little maintenance that the zlib library has seen in recent years

edit: Personally, i'm scarred from the jpeg-turbo swap which took 6 years and was an all-or-nothing. I much prefer the slow, gradual, and intentional approach.

cc: @mgorny @brainstorm @morotti

[mgorny]

I believe that jpeg/jpeg-turbo situation was quite different. Though I'm talking from Gentoo perspective, and we have switched in 2012, which made it much easier for us. My understanding is that at the time it was IJG jpeg that kept breaking backwards compatibility, so switching from libjpeg 7 to libjpeg-turbo was a win-win situation: we got better performance and avoided the worst of ABI breakage. But that's history.

As for zlib-ng, the situation is more stable: zlib is not going anywhere, and zlib-ng seems to aim to preserve "reasonable" binary compatibility. It is designed to work "mostly" as a drop-in replacement, and I don't think we should be preventing users from benefiting from that (provided it works).

The way I see it, we have three cases:

1. Package is perfectly ABI compatible with both zlib and zlib-ng(compat). We build it against zlib headers, and users can swap at runtime.
2. Package is API compatible with both. We build two variants but ideally no upstream changes are required.
3. Package is not compatible with both. We either patch it or pin the zlib variant.

The main point is that all these solutions put the burden on us, with possibility of upstream fixes.

Having packages support zlib-ng puts the burden on upstream. If we ask them to maintain compatibility with both zlib variants, that doubles the burden. If they do not wish to do that, we do disservice to distributions that aren't ready for zlib-ng. I don't know any portability problems with zlib-ng offhand, but I can very well imagine the situation where we first ask upstream to switch to zlib-ng, and then, say, NetBSD asks them to add vanilla zlib support back because zlib-ng doesn't work somewhere. I really want to avoid such a situation.

[morotti]

personally, I think that each individual package should opt-in to using zlib-ng instead of changing zlib as a whole.

I feel like you're completely missing the point in all your comments. the entire purpose of zlib-ng is to be shipped as a drop-in replacement of zlib, because applications don't get to choose what they run with, they get what is coming from their distribution.

For Windows, the official release of the python interpreter has switched to zlib-ng. (Windows is custom build that vendors selected package together, so it was easy to do).
For Linux, users need to compile the python interpreter and libraries from source, they use what comes with their OS. Fedora/arch have switched to zlib-ng.

For conda, conda is its own ecosystem handling builds and distribution.
I think the conda ecosystem needs to swap to shipping the 3.14+ python interpreter with zlib-ng in compat mode, instead of zlib.
This is required to match the official build of the interpreter, that is already using zlib-ng.

[hmaarrfk]

I feel like you're completely missing the point in all your comments

we all have many roles.

As a maintainer of zlib-ng it isn't my choice to create a library that conflicts with zlib. That issue must be raised to a wider audience.

We are doing that here.

[hmaarrfk]

cc: @conda-forge/zlib

[morotti]

IMO it's a simple problem in concept. the python interpreter has switched to using zlib-ng on windows.
the conda interpeter should switch to using zlib-ng on windows, to match. (we can ignore other OS to start with, to simplify)

the question is how to match that in the conda ecosystem? my understanding is that there isn't anybody driving python in conda-forge, so nobody who can make any decision.

from my limited understanding of how conda operates, conda builds and distributes all the libraries, together into one shared installation directory.
replacing the compression means to replace the zlib.dll with a zlib.dll built from zlib-ng.
so we merely need to modify the zlib recipe, to build zlib-ng sources instead of zlib sources?

with the way conda operates, the new zlib.dll will end up loaded by all applications that depend on zlib too (directly or through the interpreter). it's fine, it's meant to be a drop in replacement. that's what was done for the official python 3.14 binaries.

problem: conda is a single namespace, if you ship a new zlib version, it will get used by everything installing zlib at once. I think we don't want that part.
is there a way to tag new zlib/cpython releases in a way that zlib-ng is only used when using python 3.14+?

[hmaarrfk]

from my limited understanding

To help improve your understanding, you may refer to these docs

https://conda-forge.org/community/governance/
https://github.com/orgs/conda-forge/teams/core

You may find the names of the maintainers of the python-feedstock in the recipe itself.
https://github.com/conda-forge/python-feedstock/blob/main/recipe/meta.yaml#L400

is there a way to tag new zlib/cpython releases in a way that zlib-ng is only used when using python 3.14+?

The possibilities are endless, but again, we need buy-in from the existing maintainers, please give them time to respond here.

You've had many already discuss with you on the python-feedstock conda-forge/python-feedstock#821

with a patch already been worked on
jaimergp/python-feedstock#2

Please People are trying to act responsibly, to your request. please be patient and respectful.

Edit: Type from Please -> People

---

you really can't wait:

1. Create a fork of the zlib-ng feedstock
2. Create as second output from that recipe called zlib
3. Create an exact dependency on the subpackage zlib-ng
4. Set the compatibility flags on the zlib-ng compilation
5. Upload it to your channel for all platforms of interest to you
6. Share here so we can test against strange usecases.

This will give you MORE than enough breathing room to wait while a longer solution gets deployed.

If you also really can't wait you can also say:

"I'm willing to explore contract work that might enable zlib-ng to be used as a replacement for my application, please reach out to".

OSS != "free labor"

[mgorny]

SciPy hit zlib-ng related test failures on Windows py3.14 CI. Having an option to quickly swap zlib-ng and zlib would make debugging such issues much easier.

[jaimergp]

We discussed this today in the conda-forge/core call. See notes at #2636.

In jaimergp/zlib-ng-feedstock#1 I have created a twisted concoction that builds zlib-ng or zlib depending on the variant. It was a bit of nightmare to make conda-build behave, but the PR has successfully produced a set of packages that can be used to create zlib-ng-compat-supported environments.

For example, Python 3.14 on Windows with (hopefully) higher performance:

# With NG
$ conda create -n py314ng --override-channels -c jaimergp/label/zlib-ng-compat -c conda-forge python=3.14 "libzlib=*=*_ng_*"
$ conda run -n py314ng python -c "import zlib; print(zlib.ZLIB_RUNTIME_VERSION)"
1.3.1.zlib-ng

# Vanilla
$ conda create -n py314 --override-channels -c conda-forge python=3.14
$ conda run -n py314 python -c "import zlib; print(zlib.ZLIB_RUNTIME_VERSION)"
1.3.1

I also tried in my macbook and it seems to work too ✨

[brainstorm]

What about zlib-rs? It currently outpaces zlib and zlib-ng in terms of speed/convenience/safety:

https://trifectatech.org/blog/zlib-rs-is-faster-than-c/
https://github.com/trifectatechfoundation/zlib-rs
https://www.youtube.com/watch?v=-Xe9vQL0ZBY

My doubt/question here is: what would be the policy for such a (drop-in) swap in conda? Would conda swap it and flip-flop those dependencies if and when zlib-ng becomes faster than zlib-rs and vice versa?

[jaimergp]

My doubt/question here is: what would be the policy for such a (drop-in) swap in conda? Would conda swap it and flip-flop those dependencies if and when zlib-ng becomes faster than zlib-rs and vice versa?

The most likely outcome is something similar to blas. Build against the reference implementation, allow users swapping runtimes at install time by having the accelerated runtimes publish their own zlib package with a distinctive build string marker (e.g. *_ng_* for zlib-ng, *_rs_* for zlib-rs)