Search Criteria
Package Details: zlib-ng 2.0.6-2
Package Actions
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.007392 |
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)
Agree.
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-compatiblelibz.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 namedzlib-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 correctlyImperatorStorm 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 tozlib=<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 »