From: David Uhden Collado Subject: Re: [NEW] sysutils/uutils To: ajacoutot@bsdfrog.org Cc: ports@openbsd.org Date: Sun, 20 Sep 2026 20:46:00 +0000 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. > > >