Re: zlib-ng

2024-11-11 Thread Peter Jung

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/PKGBUILD

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





Re: zlib-ng

2024-11-11 Thread Jelle van der Waa




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 :)


Re: zlib-ng

2024-11-11 Thread Leonidas Spyropoulos




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