Package Details: zlib-ng 2.0.6-2

Git Clone URL: https://aur.archlinux.org/zlib-ng.git (read-only, click to copy)
Package Base: zlib-ng
Description: zlib replacement with optimizations for 'next generation' systems
Upstream URL: https://github.com/zlib-ng/zlib-ng
Licenses: custom:zlib
Submitter: hadogenes
Maintainer: Chocobo1
Last Packager: Chocobo1
Votes: 6
Popularity: 0.007697
First Submitted: 2021-03-12 09:34 (UTC)
Last Updated: 2022-11-14 06:25 (UTC)

Latest Comments

1 2 Next › Last »

Chocobo1 commented on 2022-11-14 06:36 (UTC)

Currently, this package provides zlib-ng in compat mode and replaces zlib. AFAIK, this is not 100% safe because zlib-ng is only 100% API compatible but cannot guarantee 100% ABI compatibility.

Agree.

Would it make sense to split this package into zlib-ng-compat (using the current PKGBUILD) for the brave and zlib-ng which builds zlib-ng in native mode? The second package should not have provides/conflicts=(zlib).

Done. See https://aur.archlinux.org/packages/zlib-ng-compat

MarsSeed commented on 2022-02-25 14:06 (UTC)

@MartinDiehl the goal you propose makes sense to me. I did not dare to install this zlib-replacing library on my daily driver, no matter how much I am in favor of progress and even of trying out modern software to satisfy my curiosity.

Unless and until major Linux distros take up zlib-ng and replace zlib with it and actively weed out any issues occurring with its dependents, it would be strongly favorable to have separate compat and native versions of zlib-ng as you mentioned, to decouple core zlib-ng from its compatibility layer.

The native (non-compat) package would enable developers and packagers to selectively adapt their source code and/or to configure their builds to use the native zlib-ng API.

Regarding the way to realize it in AUR: it seems it is not currently possible to configure zlib-ng to build the native libz-ng.so.2 and the legacy-compatible libz.so.1 libraries in one build run. It's an either-or choice.

Therefore it's most optimal to create a separate, standalone PKGBUILD for the non-compat version, and upload it to AUR as a new package.

In that case though, this current package should logically be named zlib-ng-compat, and the non-compat package to be named zlib-ng (or possibly, but less preferably, zlib-ng-native).

MartinDiehl commented on 2022-01-29 05:13 (UTC)

Currently, this package provides zlib-ng in compat mode and replaces zlib. AFAIK, this is not 100% safe because zlib-ng is only 100% API compatible but cannot guarantee 100% ABI compatibility.

Would it make sense to split this package into zlib-ng-compat (using the current PKGBUILD) for the brave and zlib-ng which builds zlib-ng in native mode? The second package should not have provides/conflicts=(zlib).

hadogenes commented on 2021-09-08 20:49 (UTC)

I don't understand - in zlib.h (header) there is #define ZLIB_VERSION "1.2.11.zlib-ng" (https://github.com/zlib-ng/zlib-ng/blob/develop/zlib.h) So I think the provides is set correctly

ImperatorStorm commented on 2021-09-08 06:36 (UTC)

This package incorrectly provides zlib=1.2.11, when this is not the case. provides() should be changed to zlib=<releaseVersion>.

buggs commented on 2021-08-15 22:51 (UTC)

Any plans replacing core zlib with ng?

hadogenes commented on 2021-06-04 09:07 (UTC)

@abruegmann You're right - corrected

abruegmann commented on 2021-06-04 08:18 (UTC)

Would you mind adding a proper arch tag to your PKGBUILD?

arch=('any') implies that the package runs on any architecture after building which is not the case here.

simona commented on 2021-03-17 09:38 (UTC)

thx :-(

hadogenes commented on 2021-03-17 09:15 (UTC)

no it has enabled flag ZLIB_COMPAT and it replaces standard zlib

1 2 Next › Last »