Hey All, I noticed Fedora is discussing switching from zlib to zlib-ng. zlib-ng is a fork of zlib, which seems to offer ~ 40% better performance and a new API. We have about ~ 1000 packages depending on zlib, zlib-ng does offer a compat option to keep zlib API compatibility. [1] # Proposal From a discussion in #archlinux-staff. It was determined that a possible plan would be to introduce zlib-ng as package in [extra] with the modern API enabled, we can then migrate packages over that are compatible to the new API. A zlib-ng-compat package can be provided, as proposed by Fedora, that activates the zlib API compatibility mode and directly provides libz.so. This package can provide/conflict the original zlib package, and potentially be target to replace zlib all together. In short: zlib-ng would provide libz-ng.so zlib-ng-compat would provide libz.so # Packages which might be able to use zlib-ng Alpine offers a package which has 6 required packages.[2] Debian's codesearch suggests a few packages seem to mention a possible zlib-ng compatibility. [3] These notes where written down last Thursday, in the meantime, Anthraxx uploaded zlib-ng to [extra], so we can start switching packages which use the modern API over. Replacing zlib with zlib-ng-compact is something we need to discuss, I've overheard so far that some test suites fail because they check the compressed test artifact's hash which with zlib-ng can be different. [1] https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.or... [2] https://pkgs.alpinelinux.org/package/edge/community/x86/zlib-ng [3] https://codesearch.debian.net/search?q=zlib-ng&literal=1&perpkg=1 Greetings, Jelle van der Waa & Anthraxx
Hi Jelle, As discussed in our recent IRC conversation, I believe we can move forward with the migration and push the zlib-ng and zlib-ng-compat packages, which will replace the current zlib package. There are currently not too many packages that utilize the native zlib-ng. However, we can begin migrating these packages gradually over time. To proceed, the zlib-ng and zlib-ng-compat packages should be moved to **core** instead of remaining in extra. The migration process should follow these steps: 1. Push zlib-ng and zlib-ng-compat into core-staging with the necessary replaces fields. 2. Migrate the following packages to use the native zlib-ng: - minizip-ng - gitoxide - onefetch - starship For your reference, here is an example PKGBUILD for zlib-ng and zlib-ng-compat as a split package: https://github.com/CachyOS/CachyOS-PKGBUILDS/blob/master/zlib-ng/zlib-ng/PKG... Please note that zlib-ng-compat will replace zlib The zlib-ng package does not need to be installed by default and will only be required for upcoming dependencies. The replaced zlib-ng-compat layer does not require to rebuild all packages depending currently on zlib. Best regards, Peter On 28.08.23 09:38, Jelle van der Waa wrote:
Hey All,
I noticed Fedora is discussing switching from zlib to zlib-ng. zlib-ng is a fork of zlib, which seems to offer ~ 40% better performance and a new API. We have about ~ 1000 packages depending on zlib, zlib-ng does offer a compat option to keep zlib API compatibility. [1]
# Proposal
From a discussion in #archlinux-staff. It was determined that a possible plan would be to introduce zlib-ng as package in [extra] with the modern API enabled, we can then migrate packages over that are compatible to the new API.
A zlib-ng-compat package can be provided, as proposed by Fedora, that activates the zlib API compatibility mode and directly provides libz.so. This package can provide/conflict the original zlib package, and potentially be target to replace zlib all together.
In short:
zlib-ng would provide libz-ng.so zlib-ng-compat would provide libz.so
# Packages which might be able to use zlib-ng
Alpine offers a package which has 6 required packages.[2] Debian's codesearch suggests a few packages seem to mention a possible zlib-ng compatibility. [3]
These notes where written down last Thursday, in the meantime, Anthraxx uploaded zlib-ng to [extra], so we can start switching packages which use the modern API over. Replacing zlib with zlib-ng-compact is something we need to discuss, I've overheard so far that some test suites fail because they check the compressed test artifact's hash which with zlib-ng can be different.
[1] https://lists.fedoraproject.org/archives/list/ devel%40lists.fedoraproject.org/message/CDNPJ4SOTRQMYVCDI3ZSY4SP4FYESCWD/ [2]https://pkgs.alpinelinux.org/package/edge/community/x86/zlib-ng [3]https://codesearch.debian.net/search?q=zlib-ng&literal=1&perpkg=1
Greetings,
Jelle van der Waa & Anthraxx
On 11/11/2024 09:55, Peter Jung wrote:
The migration process should follow these steps: 1. Push zlib-ng and zlib-ng-compat into core-staging with the necessary replaces fields.
In my opinion is we should move zlib-ng-compat into core as replacement for zlib but not zlin-ng until all core dependencies are moved to new API. Thoughts? -- Leonidas Spyropoulos Developer & DevOps PGP: 244740D17C7FD0EC
On 11/11/2024 10:55, Peter Jung wrote:
Hi Jelle,
As discussed in our recent IRC conversation, I believe we can move forward with the migration and push the zlib-ng and zlib-ng-compat packages, which will replace the current zlib package.
There are currently not too many packages that utilize the native zlib- ng. However, we can begin migrating these packages gradually over time.
To proceed, the zlib-ng and zlib-ng-compat packages should be moved to **core** instead of remaining in extra.
The migration process should follow these steps: 1. Push zlib-ng and zlib-ng-compat into core-staging with the necessary
David/Levente are the zlib maintainers so should pick ths up :)
replaces fields. 2. Migrate the following packages to use the native zlib-ng: - minizip-ng - gitoxide - onefetch - starship
This can be done already :)
participants (3)
-
Jelle van der Waa
-
Leonidas Spyropoulos
-
Peter Jung