This is a much cleaner way to arrange the ports, but it'd need some changes to handle the "multi-call" binaries, it looks like links from uu-ls (etc) to the binary are enough.
I'm not entirely convinced they're worth the build time though. On 2026/09/23 03:20, 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.
