Theo de Raadt wrote:
> David Uhden Collado <daviduhden@gmail.com> 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.