[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1002056: ITP: zlib-ng -- optimized zlib compression library



Package: wnpp
Severity: wishlist
Owner: Guillem Jover <guillem@debian.org>
X-Debbugs-Cc: debian-devel@lists.debian.org, Mark Brown <broonie@debian.org>

* Package name    : zlib-ng
  Version         : 2.0.5
  Upstream Author : zlib-ng Team
* URL             : http://github.com/zlib-ng/zlib-ng
* License         : Zlib, Zlib-RFC, CC-BY-3.0, CC-BY-4.0, Public-Domain
  Programming Lang: C
  Description     : optimized zlib compression library

 zlib-ng is a fork of the zlib library implementing the deflate compression
 method found in gzip and PKZIP.
 .
 It includes and consolidates many optimizations found in alternative forks,
 that have not been merged in the official zlib library.


I just discovered this project, and started packaging [P] it to be able
to play with a dpkg branch switching its zlib support to zlib-ng. The
speed up is quite significant, for example when packing the 0ad-data,
on my system it takes 5m50s~ with zlib and 4m30s~ with zlib-ng.

  [P] https://git.hadrons.org/cgit/wip/debian/pkgs/zlib-ng.git/

The project has a compat mode which generates API "compatible" zlib
replacement libraries, but unfortunately it is stated not to guarantee
to be ABI compatible, so no compat packages or similar could be
produced right now as that could potentially break other packages. I've
filed a report [S] upstream to request a more usable shim instead.

  [S] <https://github.com/zlib-ng/zlib-ng/issues/1081>


I'm still pondering whether to upload this, although the packing is
already done, but w/o the above mentioned shim its utility seems
restricted as most upstream projects use it via its compat mode,
instead of with its native API. But if that happens, I think it would
make sense to upload, as it's currently being embedded in several
upstream projects and even if dpkg would not switch to it, it would
still help with removing embedded code copies, and speeding up other
packages. Or make other RPFs such as #901490 (an alternative fork)
unnecessary.

Thanks,
Guillem


Reply to: