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
