@oech3 Thanks for the comment(s). I honestly try my best to be in-line and follow the dependencies and the build steps that they have on the official Arch repo's uutils-coreutils package. That's why I have the same depends and makedepends as the official package.
One of the main goals of this package is to make sure it contains most (if not all) files that the packages in conflicts=() and provides=() has, since it is a risky replacement to a core part of someone's OS. I also make sure that the package is stand-alone, without needing to submit several new packages to the AUR for the missing libraries/manpages/utilities. That's why I include manpages, shell completions, and libstdbuf.so (even if it seems unneeded) since that's what the upstream coreutils Arch package provides.
This is also why I'm a bit hesitant to use symlinks to the uutils-coreutils files, because it is possible that the upstream uutils-coreutils package could re-implement where the files are located, not use prefixes, and just implement it the same way that the 9base and plan9port packages does (similar to how debian implements rust-coreutils). If some users don't use an AUR helper this could lead to them having an unbootable system. So for right now, I am deciding to keep this package "as is".
With all that said, I do appreciate your work with coreutils-uutils-symlink and coreutils-uutils-selinux package and I'm glad that users have that option in the AUR, so thank you.
Pinned Comments
oech3 commented on 2025-09-08 09:52 (UTC) (edited on 2025-09-15 15:44 (UTC) by oech3)
/usr/local/binis safer than this.-gitand-selinux.Building same binary avaiable from repo and symlink only pkg is not allowed at AUR. Don't believe that this is avaiable until officlal drop-in appear.