Anthony J. Bentley wrote:
> David Uhden Collado writes:
>> 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.
> 
> uutils could fit in ports like so: keep it to one package per upstream
> distfile, with the generic utility names installed to /usr/local/bin
> with a uu- prefix. I could also see it working like plan9port, off in
> its own directory a user could put in PATH, if it can be done without
> making the port too complicated. But we don't want uutils names to
> clobber programs already in /usr/local/bin.
> 
> Even if the software is worth porting, there is no appetite here to
> replace GNU coreutils dependencies in ports with uutils. Let Canonical
> have their fun doing so; it's mostly irrelevant to us.
> 
> What you've proposed beyond that is too complex. Consolidating multiple
> distfiles into one port and then splitting it into MULTI_PACKAGES is too
> complex; uutils doing *anything* related to replacing or conflicting
> with GNU coreutils dependencies is too complex.
> 
> The comments are all wrong. A consumer of the cargo module should not
> be documenting cargo module internals. And comments about patches don't
> belong in the Makefile, they belong in the patches themselves.
> 
> This has been a running theme with AI-generated ports: the ports are
> way too complicated, and the emails describing them are too verbose
> to bother reading. Your port makefile was 218 lines. How many port
> makefiles are over 200 lines long? Does it make sense for this port to
> be as dense as webkitgtk4 or ghc? Your first mail was 15 paragraphs.
> When's the last time you saw someone else post even a sophisticated,
> highly technical patch to ports@ with 15 paragraphs of explanation?
> 
> For developers to spend any time looking at them, contributed ports need
> to be simple. The emails accompanying them need to be clear and concise.
> 
> AI is not directly the problem; a lovingly handcrafted uutils port
> with 200 lines of MULTI_PACKAGES and @conflict with the GNU tools
> would be just as unacceptable. And yet, it sure is a funny coincidence
> how ports made with AI assistance keep consistently looking like this.
> 
> Attached is my take on a uutils port. I made it the same way I make any
> other port, using the default install targets, avoiding any fancy stuff,
> and left out programs that upstream hasn't released yet. I'll import
> this if another developer gives me an ok.

Hi Anthony,

The main thing I find interesting about uutils is not that it is written 
in Rust, but that it provides permissively licensed replacements for GNU 
utilities.

Rust does make AI-assisted development easier because the compiler 
catches many mistakes and forces a certain level of correctness instead 
of allowing obviously broken code, such as code with memory-safety 
problems. But that is secondary. The real value of uutils, in my view, 
is as an alternative implementation of GNU-compatible tools.

That is why I do not see much value in porting uutils coreutils, 
findutils, grep, etc. if they can never be considered as alternatives 
for satisfying dependencies on the corresponding GNU tools. Given the 
compilation cost, installing another copy of the same utilities under 
different names has fairly limited usefulness.

I also disagree that Canonical's work on this is irrelevant. If 
anything, it makes uutils more relevant because it means these 
implementations are being actively tested in real systems. This is not 
just some teenager's vibecoded GitHub project. Microsoft also ships 
uutils for Windows, including coreutils, findutils, and grep, even 
though some of those projects are not fully stable yet [1].

Regarding the port structure, Rust software has a strong tendency toward 
large, centralized dependency graphs, and uutils itself is already built 
around multicall binaries. Splitting every upstream project into a 
separate port does not remove the complexity of exposing the individual 
utilities; it mostly means repeating the same symlink mechanism in 
several ports.

It may also be worth considering whether the Cargo module could 
eventually reuse identical crates between related ports or 
MULTI_PACKAGES. That could reduce download time, bandwidth, and build 
storage. That is obviously a separate issue from whether this particular 
port should be imported.

As for AI, I think reducing the discussion to "the Makefile is too long" 
or "the email is too long to read" is a poor argument against 
complexity. It effectively defines acceptable complexity according to 
what someone feels like reviewing manually rather than according to what 
the software actually requires.

Software is not becoming simpler. A lot of the software that makes 
OpenBSD useful already carries dozens of patches, complicated dependency 
graphs, and substantial integration work. If humans are unwilling to 
manage that complexity and automation is rejected as well, I do not see 
how that scales.

I already find it unfortunate that much of ports is only weakly 
integrated with OpenBSD. Very little third-party software makes serious 
use of OpenBSD-specific security mechanisms, and some software even 
requires relaxing protections such as W^X on the filesystem where it is 
installed. I do not see many people volunteering to solve that problem 
manually at scale either.

So I think the real question is what the objective is: improving the 
system and finding ways to manage increasing complexity, or keeping 
things roughly as they are because anything more ambitious is considered 
too complicated.

References:

[1]: https://github.com/microsoft/coreutils