Package Details: uutils-coreutils-symlinks 0.2.0-2

Git Clone URL: https://aur.archlinux.org/uutils-coreutils-symlinks.git (read-only, click to copy)
Package Base: uutils-coreutils-symlinks
Description: WARNING - CONFLICTS WITH COREUTILS ; USE AT YOUR OWN RISK. Symlinks uutils to appropriate binaries, alongside with man pages, and shell completions
Upstream URL: https://uutils.github.io/
Licenses: MIT
Conflicts: b3sum, coreutils, sha3sum
Provides: b3sum, coreutils, coreutils-uutils
Submitter: sga013
Maintainer: sga013
Last Packager: sga013
Votes: 1
Popularity: 1.00
First Submitted: 2025-09-08 19:57 (UTC)
Last Updated: 2025-09-08 21:17 (UTC)

Dependencies (2)

Required by (1248)

Sources (0)

Latest Comments

oech3 commented on 2025-09-09 05:49 (UTC)

Interesting. Is seems bash completes cp --progress without additional file.

sga013 commented on 2025-09-08 21:31 (UTC) (edited on 2025-09-08 21:33 (UTC) by sga013)

Collection of symlinks covered by symlink to /usr/local/bin

I did not know about this rule. I mostly just checked the wiki for aur submission guidelines, and general pkgbuild practices. I can change it, but my only guess for problems is that /usr/local/bin is not always in $PATH, so one would have to add it in path, but that does not seem great for stuff like coreutils.

Building same binary avaiable at official repo

but it is not building the same binary. I would like to just repeat the nvim-symlink argument for this.

I understand there was a argument that this has much less users than nvim one, but if no one uses it, it's feature parity is going to take longer, and so on.

I'm also considering to send a deletion request to coreutils-uutils BEFORE drop-in appear at official repo.

they can effectively do that in a jiff by just removing the uu- prefix for symlinks. The reason (as i understand) that it is not done is to allow coexistence, so someone may not accidentally encounter some incompatibilty issue. One can argue that "potentially alpha" software should not be in official repos, but a significant amount of packages are in similar vain. for example, 0ad, has been in a "alpha" for forever, and it is understood that it is as stable as it is going to be.

Debian package for uutils places all bins to /usr/local/bin/cargo/ (not sure, but i think i read it in one of uutils issues), but that has a similar problem of adding to path.

oech3 commented on 2025-09-08 20:48 (UTC) (edited on 2025-09-08 20:51 (UTC) by oech3)

Actually, both package is violating with rule of AUR:

  1. Collection of symlinks covered by symlink to /usr/local/bin.
  2. Building same binary avaiable at official repo.

I'm also considering to send a deletion request to coreutils-uutils BEFORE drop-in appear at official repo.

sga013 commented on 2025-09-08 20:16 (UTC) (edited on 2025-09-08 20:18 (UTC) by sga013)

I mostly took this pkgbuild from a now deleted coreutils-uutils-symlink aur package (from the git history). The original maintainer is unknown to me, but major credits to them.

I found some discussion on forum related to duplication, and also aur-requests mailing lists, where there were a lot of mails regarding this (https://lists.archlinux.org/archives/search?mlist=aur-requests%40lists.archlinux.org&q=uutils) old package and adjacent packages, but specifically regarding symlink package, there was a thread for merging with coreutils-uutils as that package was submitted earlier (https://lists.archlinux.org/archives/list/aur-requests@lists.archlinux.org/thread/5JWN5T5J3GD5XR63WGLAU2EICZ2QP6EG/#5JWN5T5J3GD5XR63WGLAU2EICZ2QP6EG), but I do not think they are both same packages. One builds packages, and other just symlinks. to end user, they may seem same, but symlink package avoids all build dependencies.

As the package was deleted or the developer abandoned, this was stuck, and as a new release for uutils happened this week, I wanted to use it, but old package build had fixed pkgversions, as well as depended on uutils-stty package which no longer exists, so I could not update. I just simplified the pkgbuild, and it seems to be working.

Symlinking is still one of the best ways to try uutils. I used uutils, and hence encountered a bug in wild that files were not being cleanly flushed when copying from buffers (this fix was released in the latest release), but I would have not encountered this unless i was specifically using uu-cp in a completely unrelated scenario, where i was just using cp.

I can accept deletion of this package when either uutils either almost completes there feature parity with gnu version, or when are uutils package stops adding the "uu-" prefix to symlinks (which they would likely only do once it is almost done). So until then, please let this package exist.