zlib vs zlib-ng

As above, I see Compton has been replaced with Picom likely due to its sheer lack of development over the last couple of years.

What about replacing zlib for zlib-ng for the exact same reasons? Or at least take it in to serious consideration.

The last commit to zlib was over almost 3 years ago, despite many pull requests being made for improvements. This is why the zlib-ng project was started and as you can see is in active development merging many of the fixes proposed for zlib that continue to go ignored.

Anyway, just a thought.

:slightly_smiling_face:

1 Like

Considering that zlib is critical software that is a dependency of a lot of other programs, I do not think replacement can be taken as lightly as with something like Compton. Is it ready to be used? Is it ready to actually replace zlib? Is zlib-ng actually compatible with zlib, or all pieces of software that depends on it needs to adapt their code for it? Can we be be relatively sure that it will be maintained in long term?

Plus, we are taking zlib from Arch Linux. I think we should see what Arch will do with it, and adapt to the change if there is any.

This is something that could be suggested on Arch Linux side, though.

1 Like

From the github link in the OP:

The idea of zlib-ng is not to replace zlib, but to co-exist as a drop-in replacement with a lower threshold for code change.

1 Like

Forum kindly sponsored by