#1126716 RFP: fdzipstream -- ZIP On-the-fly Streaming Library in C

Package:
wnpp
Source:
wnpp
Submitter:
Xavier Del Campo Romero
Date:
2026-02-14 10:07:02 UTC
Severity:
normal
#1126716#5
Date:
2026-01-31 12:34:37 UTC
From:
To:

* Package name    : fdzipstream
   Version         : 1.0.0
   Upstream Author: CTrabant <ctrabant@gmail.com>
* URL             : https://github.com/CTrabant/fdzipstream.git
* License         : Apache 2.0
   Programming Lang: C
   Description     : Create ZIP archives in streaming fashion, writing
to a file descriptor.

fdzipstream allows to generate ZIP files on-the-fly and send them over a
networked
connection, so that it is not needed to have the entire file in disk or
memory
before transmission.

fdzipstream is also a dependency for slcl.
#1126716#10
Date:
2026-02-13 22:24:49 UTC
From:
To:
Am 31.01.2026 um 13:34 schrieb Xavier Del Campo Romero:

Hello,

AFAICT this can also be done using UNIX zip, like this:

hille@rasppi3:~/t1/fdzipstream $ zip - zipfiles.c | base64
   adding: zipfiles.c (deflated 68%)
UEsDBBQACAAIAPO0TVwAAAAAAAAAAN4VAAAKABwAemlwZmlsZXMuY1VUCQADGZqPaUuaj2l1eAsA
<snip>

So, what is the main advantage of this program, except that it is
smaller than UNIX zip?

Hilmar
#1126716#15
Date:
2026-02-13 23:22:36 UTC
From:
To:
Hello Hilmar,

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.

Best regards,

Xavi

[1]: https://gitea.privatedns.org/xavi/slcl
#1126716#20
Date:
2026-02-14 09:34:14 UTC
From:
To:
Am 14.02.2026 um 00:22 schrieb Xavier Del Campo Romero:

Hello,
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
#1126716#25
Date:
2026-02-14 10:05:59 UTC
From:
To:
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