Antoine Jacoutot wrote:
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?
The difference between bat and cat from uutils is that bat is trying to
provide a different tool with additional features, while uutils cat is
specifically intended to reproduce the behavior of GNU cat as closely as
possible.
I'm generally not a fan of replacing established tools with alternatives
that have different behavior or semantics. For me, tools like bat,
ripgrep, eza, and similar replacements tend to introduce more friction
than they solve, precisely because they are not drop-in replacements for
the original utilities.
That is why I find projects like uutils more interesting: the goal is
compatibility with existing GNU behavior rather than redefining how the
tool should work.
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.
I tried to bundle the uutils projects that I thought were relevant into
a single port and split them with MULTI_PACKAGES.
I can see how that may not fit well with the usual ports structure,
especially since they are separate upstream projects and may need to be
built, tested, and maintained independently. It could also make the test
stage more awkward if one component fails while the others are fine.
Splitting them into separate ports would probably make the structure
cleaner and make it easier to handle updates, dependencies, and tests on
a per-project basis.
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.
As I said, this is experimental, but in some cases it may still be
useful. If the find implementation from uutils works for someone as a
substitute for GNU find when running a particular script, then they can
simply keep using it.
Giving these implementations a different prefix and avoiding symlinks
with the GNU-compatible names would certainly prevent conflicts. The
downside is that it would also make them less convenient for people who
actually want to use them as drop-in alternatives and test whether they
work for their specific use case.
For an experimental package, I think there is some value in making that
kind of testing straightforward, as long as the user is explicitly
choosing the alternative implementation and understands that
compatibility may not yet be complete.
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.
