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.
uutils.tar.gz
Description: GNU Zip compressed data
