I agree that upstream Makefile is not of much value. In fact, slcl defines their own from a parent directory so fdzipstream can be effectively used as a library. [1][2]
Telling upstream to provide a more useful/meaningful build system would be a good suggestion IMHO. But how much of a hard requirement is this from the perspective of Debian packaging? Best regards, Xavi [1]: https://codeberg.org/xavidcr/slcl/src/commit/1e93a53bc43e5111346d9cca64d2dd3b25c0e4ca/fdzipstream/Makefile [2]: https://codeberg.org/xavidcr/slcl/src/commit/1e93a53bc43e5111346d9cca64d2dd3b25c0e4ca/fdzipstream/CMakeLists.txt On 14 February 2026 10:34:14 CET, "Preuße, Hilmar" <[email protected]> wrote: >Am 14.02.2026 um 00:22 schrieb Xavier Del Campo Romero: > >Hello, > >> As opposed to zip(1), fdzipstream is not an executable, but a C library. It >> is therefore meant to be embedded into other applications, adding zlib as >> its only dependency. For example, slcl [1] embeds fdzipstream to compress >> zip files on-the-fly from C (and send them over the network), rather than >> having to rely on an external process as you suggested. >> >The upstreams Makefile [1] currently just generates two executables > >all: zipexample zipfiles > >What am I missing? > >Hilmar > >[1] https://github.com/CTrabant/fdzipstream/blob/main/Makefile
