Theo de Raadt wrote:
David Uhden Collado <[email protected]> wrote:
Stuart Henderson wrote:
On 2026/09/20 07:01, David Uhden Collado wrote:
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.
...
Each package conflicts with its corresponding GNU implementation and
declares the GNU port as a secondary @pkgpath.
I don't think this is a usable approach for ports.
The truth is, I find these Rust reimplementations quite
interesting. Ubuntu 26.10 has already adopted uutils coreutils because
the project has reached a level of maturity and stability where it can
be used reliably. The other reimplementations are still more of a work
in progress.
Smells like agenda.
I also think they fit quite well with OpenBSD as alternatives to GNU
utilities, particularly because they use a permissive MIT license.
Argument is vaguely like: because we already have permissive licenced
utilities, our user base are really interested in having a second set of
permissive licenced utilities which are very subtly different.
That makes no sense. Noone wants subtly different behaving binaries as
part of their workflow. If someone runs the openbsd ls command as part
of a pipeline that uses openbsd sed, or openbsd cut, or some other
openbsd utility and it parses a non-standized output characteristic
by accident, there are no people in this universe who wants to replace
that ls with a different ls and get surprised by un-standardized tooling
behaviour clash.
I'm not sure yet whether it's possible to install the individual
utilities as separate binaries. This is new territory for me, since
uutils is structured as a metapackage, and because it's written in
Rust.
Oh, because it is written in Rust.
Your agenda is showing.
There is no agenda here. My goal is simply to have alternatives for
software that already depends on GNU utilities in order to work
correctly on OpenBSD.
I have always found it somewhat unfortunate that some ports need GNU
coreutils, bash, or other GNU utilities rather than being able to use
the base system tools. Where those dependencies cannot reasonably be
removed because the software genuinely relies on GNU semantics or
extensions, I think having another compatible implementation available
is useful. It is simply about having a choice.
I am not suggesting replacing OpenBSD's base utilities, nor do I want
subtly different implementations appearing unexpectedly in users' normal
workflows. That was never the objective. The intended use case is
specifically software which already expects GNU-compatible utilities and
currently depends on the corresponding GNU ports.
Besides coreutils, there are other projects reimplementing GNU software
in Rust under permissive licenses, such as other uutils projects and
brush. They are not yet 100% compatible with their GNU counterparts, so
I would not claim that they are ready to replace them everywhere today.
But I expect compatibility to continue improving over time.
And no, my interest is not simply "because it is written in Rust." Rust
is relevant to the packaging because it determines how the port has to
be built. The implementation language itself is not the objective.
I also do not understand the hostility towards these projects. If the
concern is that AI or LLM-assisted development may have been involved,
that is a separate discussion from whether the resulting software is
technically useful, compatible, maintainable, and suitable for ports.
LLMs can substantially reduce the amount of time required for some kinds
of software development, including work that would previously have
required much more manual effort. I think the sensible way to judge the
result is by the code, tests, compatibility and maintenance quality
rather than by assuming that the development method itself makes the
project undesirable.
In any case, I would rather keep that discussion separate. My interest
here is much simpler: providing additional permissively licensed
alternatives for ports that already require GNU-compatible tooling.
