Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide zlibWrapper as a shared library #4277

Open
Apteryks opened this issue Jan 31, 2025 · 3 comments
Open

Provide zlibWrapper as a shared library #4277

Apteryks opened this issue Jan 31, 2025 · 3 comments
Assignees

Comments

@Apteryks
Copy link

Is your feature request related to a problem? Please describe.
Currently, making use of the zlibWrapper requires a project copying a few (5) source files from this project, and building those files as part of their build. It would be simpler to simply link to a zlib-wrapper.so library provided by zstd.

Describe the solution you'd like
The build system of zstd would be extended with a target to build zlib-wrapper as a (shared) library and register it so it gets installed as part of the regular install phase.

Describe alternatives you've considered
None.

Additional context
This came up while proposing to contribute zstd-decompression support (via zlibWrapper) to mandoc (see: https://inbox.vuxu.org/mandoc-discuss/[email protected]/).

@ischwarze
Copy link

Thanks to Maxim for opening this feature request.
Let me explain concisely, but with sufficient detail to understand why this matters. what the point of the feature is.

  1. As the maintainer of the mandoc project, which provides an enhanced implementation of the man(1) program mandated by POSIX, i consider compression - any kind of compression, that is! - as a feature that is completely pointless for manual pages in this decade because the space savings are so tiny that they are completely irrelevant for any practical purpose.
  2. However, the mandoc program is widely offered to users by many operating systems, including four different BSD systems, illumos. macOS and more than ten different Linux dustributions including openSUSE, Fedora, Gentoo, Debian, Ubuntu, Arch, Alpine, Void, Guix and others. Some of these systems insist on compressing installed manual pages. I think that's a foolish decision, but it's their choice, and convincing dozens of operating systems of adopting any particular policy is just not realistic, no matter how good technical arguments may be.
  3. I consider code cleanliness and simplicity of utmost importance. In particular, that requires keeping code that provides no technical benefit to the minimum.
  4. Items 1, 2, and 3 together cause an obvious conflict. As a compromise, in the past, i agreed to provide support in mandoc for manual pages compressed with zlib for those systems that - for whatever reasons - insist on compressing installed manual pages.
  5. Now some systems - including Guix - have started compressing their manual pages with zstd instead of zlib, which means that mandoc no longer works for them.
  6. This exacerbates the conflict. Further complication of the mandoc code is clearly not acceptable for a feature that is not technically useful in the first place. Also, adding additional source files to the mandoc repository is not acceptable. It would be too messy, and it would cause a risk that such files fall out of date. Generally, importing copies of outside projects into a source repository creates a maintenance nightmare and sets up the stage for subsequent security debacles when vulnerabilities are found and the copies have to be tracked down into multiple projects.
  7. Having your zlib wrapper installed as a shared library would allow to confine the complication purely to the configuration system of application programs like mandoc, without further invading the source code, which would be acceptable as a compromise. It would make sure that vulnerabilities that may later be found in the wrapper library would be dealt with by the maintainers of the operating system using and packaging the wrapper library, and would not be the responsibility of the maintainer of individual application programs like mandoc.

Thank you for your consideration,
Ingo Schwarze, member of the mandoc, GNU roff, and OpenBSD projects

@Cyan4973
Copy link
Contributor

Cyan4973 commented Feb 1, 2025

We could probably create a build target for such a shared library.

Would it be enough for this request ?

@Apteryks
Copy link
Author

Apteryks commented Feb 2, 2025

We could probably create a build target for such a shared library.

Would it be enough for this request ?

Hello! I think so, yes!

@Cyan4973 Cyan4973 self-assigned this Feb 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants