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
