Re: [NEW] mkz - archivers/mkz 0.1.0- a reversible columnar pre-pass + zstd archiver

Hello Stuart,

Thanks for the feedback! And for the package help. Thought would be clean
if I addressed and bumped to 0.1.2 so the source and the port line up, too.

- Also cleared up some license noise and trimmed to "# MIT OR Apache-2.0.. "
and dropped the WANTLIB on a handful of files.
- Am using the standard infrastructure now (MAKE_FLAGS / FAKE_FLAGS
/ TEST_TARGET = check).
- PLIST regenerated with make update-plist (@bin bin/mkz + man/man1/mkz.1).
- WRKDIST gone and the 0.1.2 distfile roots at ${DISTNAME}/ (standard layout)
- Added  ${CPPFLAGS} on the container test so <zstd.h> is found and
 is upstream in the Makefile now.
- Cool -- .012 Distfile: mkz-0.1.2.tar.gz at the SITES URL, distinfo
regenerated.

Did a build and port-lib-depends-check clean on 7.9/arm64 before I pushed the
tgz, after clearing out as many em dashes as I could -- Updated tgz's
attached. :)

Please let me know if I this looks more in line or anything else I
should catch?

Thank you!
Matt

On Wed, Jul 8, 2026 at 6:02 AM Stuart Henderson <[email protected]> wrote:
>
> On 2026/07/06 12:39, Matt Klein wrote:
> > Hello,
> >    Please find Attached, a new port archivers/mkz that I published at:
> > https://github.com/gitspoked/mz called `mkz` and also in rust/crates.rio.
> > I am looking to push to ports.
> >
> > TLDR: `mkz` is a tar-style archiver whose backend is a reversible, schema-free
> > auto-columnar transform (autocol) followed by zstd. It is not a new
> > compressor: the transform reshapes line-oriented data (logs, CSV, JSONL)
> > so zstd sees per-column-homogeneous streams. Its product is measurably
> > smaller on that kind of data, and behind a per-block never-worse gate.
> > Provably never larger than zstd alone. Archives carry an end-to-end SHA-256,
> > verified on extract.
> >
> > This is a pure-C upstream build: six C files, depends on libzstd only;
> > we have vendored SHA-256 and base-95. It is byte-compatible in both
> > directions with the Rust reference implementation, and the wire format
> > is specified: https://github.com/gitspoked/mkz/blob/main/FORMAT.md
> >
> > Tested on 7.9/arm64: distinfo reproduces from the hosted release
> > tarball via the the framework fetch; make / make fake / make package /
> > make test  upstream's three test programs --
> > port-lib-depends-check all clean; portcheck clean.
> >     - attached: mkz-obsd-port.tgz.  digest 9a7fe784…
> >     - exact tarball was revalidated
> >
> > The C port was made from the Rust implementation with an OpenBSD first-target
> > I know how vigorously accountable you hold security standards to
> > within this circle.
> > I figured, before I submitted to any other ports trees, why not see if
> > we can break it
> > apart here first, to be sure.
> >
> > I am upstream and listed on MAINTAINER; I am happy to take feedback and
> > keep the port current. Please let me know if you have any questions. Thx
> >
> > Thank you,
> > Matt Klein
> > [email protected]
> > [email protected]
>
> : # mkz is dual-licensed MIT OR Apache-2.0.
> : PERMIT_PACKAGE =      Yes
>
> ports Makefiles aren't meant to be chatty; just use
>
> # MIT OR Apache-2.0
> PERMIT_PACKAGE =        Yes
>
> : # Links libc and libzstd only (SHA-256 and base-95 are vendored).
>
> I'd drop that too
>
> : WANTLIB =             c zstd
> :
> : SITES =               https://github.com/gitspoked/mkz/releases/download/v${V}/
> :
> : # The release tarball extracts to mkz-c/ (the pure-C tree), not ${DISTNAME}/.
> : WRKSRC =              ${WRKDIR}/mkz-c
>
> should be WRKDIST not WRKSRC
>
> also needs FIX_EXTRACT_PERMISSIONS = Yes due to restrictive file modes
> in the tar
>
> : LIB_DEPENDS =         archivers/zstd
> :
> : # Plain handful of C files - no configure, and no GNU make needed
> : # for the port build.
>
> it's simpler for upgrades if you use the standard project's build/test/
> install infrastructure, which isn't hard to do, and needs no additional
> deps.
>
> PLIST should be generated with "make plist" (which adds annotations to
> binaries, amongst other things).
>
> not a big fan of the asciified em-dashes in DESCR.
>
> suggested alternative tgz attached.