Fedora Account System
Red Hat Associate
Red Hat Customer
spec: https://fed500.fedorapeople.org/zlib.spec srpm: https://fed500.fedorapeople.org/zlib-1.3.2-1.fc43.src.rpm description: Zlib is a general-purpose, patent-free, lossless data compression library which is used by many different programs fas: fed500 Rationale for bringing this back to Fedora: The package was replaced by zlib-ng which provides a compat package. However, zlib-ng uses compression algorithms that are not fully deterministic, as such cannot be used in pipelines that require reproducible builds and use checksums on compressed artifacts. One way to have both zlib-ng and zlib is to use modules, though other suggestions are welcome. Previous discussion: https://fedoraproject.org/wiki/Changes/ZlibNGTransition Reproducible: Always
Copr build: https://copr.fedorainfracloud.org/coprs/build/10200642 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2445516-zlib/fedora-rawhide-x86_64/10200642-zlib/fedora-review/review.txt Found issues: - No gcc, gcc-c++ or clang found in BuildRequires Read more: https://docs.fedoraproject.org/en-US/packaging-guidelines/C_and_C++/ - A package with this name already exists. Please check https://src.fedoraproject.org/rpms/zlib, https://src.fedoraproject.org/tests/zlib Read more: https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#_conflicting_package_names Please know that there can be false-positives. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
(In reply to Benson Muite from comment #0) > > The package was replaced by zlib-ng which provides a compat package. > However, zlib-ng uses compression algorithms that are not fully > deterministic, as such cannot be used in pipelines that require > reproducible builds and use checksums on compressed artifacts. One > way to have both zlib-ng and zlib is to use modules, though other > suggestions are welcome. > > Previous discussion: > https://fedoraproject.org/wiki/Changes/ZlibNGTransition > > Reproducible: Always Have you reached out to the Fedora Reproducible Builds folks about this? This is the first time I'm hearing of this.
Very few artifacts shipped in Fedora is gzipped I think so it's not a problem for distribution as such, however having a deterministic zip command available in distro is important for several use cases.
Is this the same issue or something else? https://github.com/zlib-ng/zlib-ng/pull/2102 - Make deflate output deterministic if PREFIX3(stream) is reused after deflateReset
Non-deterministic compression would be very bad. I hope it's just the above bug which is already resolved.
Sorry, believe they are deterministic but not stable from release to release: https://github.com/zlib-ng/zlib-ng/issues/2216
(In reply to Benson Muite from comment #6) > Sorry, believe they are deterministic but not stable from release to release: > https://github.com/zlib-ng/zlib-ng/issues/2216 I would point out that identical compressed stream output across compressor versions for particular settings is not something that ought to be relied upon in general. It imposes unreasonable constraints on the implementation and prevents useful improvements. It was never formally guaranteed even by zlib as far as I know, but people have gotten used to it because the zlib implementation has been so stable (or stagnant, depending on how one sees it) for so many years. You will certainly see compressed streams changing from version to version in the reference implementations of other popular compression formats, like zstd. The package proposed here would (currently, implicitly) conflict with the zlib-ng-compat package, which causes all sorts of problems and isn’t generally allowed. See https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/#_library_name_conflicts. It seems like this review is basically intended to suggest reverting https://fedoraproject.org/wiki/Changes/ZlibNGTransition, although I see that you mentioned (but did not implement) the idea of making the zlib implementation switchable using environment modules. I personally think that the right answer is to stop relying on the mostly-accidental stability of compressed data streams produced by the zlib reference encoder across releases, but *if* you feel there is adequate justification to reintroduce the reference zlib package and add the complexity of something like environment modules, it would be appropriate to engage the zlib-ng maintainers (since their package would also need changes to make this work), and to go through the System-Wide Changes process.
FESCO resolution is to allow it if the binary name is changed: https://pagure.io/fesco/issue/3575
I see, then the spec file would need to be adjusted to provide a special-purpose zlib library with nonconflicting file paths, including at least the shared library and its SONAME, and preferably also the headers and .pc file, and “with a name and description that make it clear that is not to be used as the default implementation,” in order to comply with https://pagure.io/fesco/issue/3575#comment-1009008. It would probably also be a good idea to minimize the package, omitting e.g. the static library unless there is a specific technical need for it.