On Sun, Sep 20, 2026 at 07:01:00AM +0000, David Uhden Collado wrote:
> Hello ports@,
> 
> Please find attached a new port for uutils:
> 
> sysutils/uutils
> 
> uutils is a family of cross-platform reimplementations of the GNU
> utilities written in Rust:
> 
> https://uutils.github.io/
> https://github.com/uutils
> 
> The port is structured as a multi-package port. The main
> sysutils/uutils package is a meta-package that installs:
> 
> uutils-coreutils
> uutils-findutils
> uutils-diffutils
> uutils-grep
> uutils-awk
> uutils-sed
> uutils-tar
> 
> The primary coreutils package is currently based on uutils/coreutils
> 0.12.0. The other components are built from their respective uutils
> projects and pinned releases or commits.
> 
> The main goal of the packaging is to make these implementations usable
> as alternatives to the existing GNU utility ports without requiring
> source changes in dependent ports.
> 
> For example, uutils-coreutils installs the same g-prefixed command names
> as sysutils/coreutils, including gcat, gls, gcp, gdate, gsort, gstat,
> gtail, gtimeout and the other GNU-compatible utilities. They are
> symlinks to the upstream multicall binary, which is installed under
> libexec/uutils.
> 
> libstdbuf.so is also installed in the same location used by
> sysutils/coreutils so gstdbuf continues to work as expected.
> 
> The other subpackages follow the same approach:
> 
> uutils-findutils:
>     gfind, gxargs, glocate, gupdatedb
> 
> uutils-diffutils:
>     gdiff, gcmp
> 
> uutils-grep:
>     ggrep, gegrep, gfgrep
> 
> uutils-awk:
>     gawk
> 
> uutils-sed:
>     gsed
> 
> uutils-tar:
>     gtar
> 
> Each package conflicts with its corresponding GNU implementation and
> declares the GNU port as a secondary @pkgpath. This means that a port
> which currently depends on, for example:
> 
> sysutils/coreutils
> misc/findutils
> textproc/gdiff
> sysutils/ggrep
> lang/gawk
> textproc/gsed
> archivers/gtar
> 
> can be tested with the corresponding uutils subpackage by changing the
> dependency, while keeping the command names used by the port unchanged.

I think this is a very bad idea.
You cannot assume these are drop-in replacements.
They should be installed with a name that does not pretent to be what it is not.
Also it seems the port is providing gcat.
We already have sysutils/bat.
How many rust alternatives to basic Unix tools do we need?

Also I don't understand the structure of this port.
You are bundling several things that should all be its own port into a big
port which you split in MULTI_PACKAGES.
From a ports stand point, that doesn't make sense.

> This is not intended to claim complete compatibility yet. There are
> still some relevant upstream limitations. uutils-diffutils does not
> currently provide diff3 or sdiff, uutils-awk is still primarily a POSIX
> implementation and does not implement the full set of GNU awk
> extensions, and uutils-tar does not provide the grmt remote helper.

Another reason not to pretend these a gfoo replacements.

> The port uses devel/cargo and builds the seven independent Rust
> projects from one ports entry. crates.inc is therefore the union of the
> Cargo.lock dependency sets from all of the projects rather than the
> output of a single Cargo workspace.
> 
> The Cargo infrastructure replaces vendored native libraries where
> possible. uutils-findutils and uutils-grep use textproc/oniguruma, while
> uutils-tar uses the system archivers/zstd library.
> 
> uutils-awk and uutils-tar currently contain git dependencies that cannot
> be obtained from crates.io. The port fetches those repositories with
> DIST_TUPLE and patches Cargo.toml to use the local checkouts, preserving
> the ports requirement that builds do not access the network.
> 
> There is also a small OpenBSD-specific patch for uutils-awk. Its
> release-mode LinearReg leak assertion produces a false positive when
> compiled with the ports panic=unwind profile, because unwind cleanup
> paths instantiate Drop and trigger the compile-time assertion. The
> upstream comment explicitly permits removing this check when it causes
> false positives, so the port disables that release-only assertion.
> 
> The port is intended both for users who want the Rust implementations
> and as a basis for testing whether existing ports that currently require
> GNU userland utilities can use the uutils implementations instead.
> 
> Thank you for your time and consideration.
> 
> Best regards,
> David.



-- 
Antoine