Question about -dev thread "Introduction of app-alternatives/coreutils"

Howdy,

I follow -dev.  Sometimes it gives me a heads up to changes.  This is 
one I don't get.  Keep in mind, I have no idea of what is going on with 
these packages upstream.  I have no idea why this is happening at all.  
I think someone mentioned a license issue or something but that sounded 
like it was already corrected.  To be honest, one shouldn't need to, as 
a user, track upstream on every package one uses.  Still, this is 
confusing to me and my concern, it may confuse others as well.  This is 
what I currently have installed and in the tree.



root@Gentoo-1 / # equery list -p sys-apps/coreutils
  * Searching for coreutils in sys-apps ...
[-P-] [  ] sys-apps/coreutils-9.9-r1:0
[IP-] [  ] sys-apps/coreutils-9.9-r12:0
[-P-] [ ~] sys-apps/coreutils-9.10:0
[-P-] [ -] sys-apps/coreutils-9999:0
root@Gentoo-1 / #



Now something called uutils-coreutils is coming into the picture and as 
long as what I have works, I don't plan to switch.  Reading some other 
posts, this new package isn't the most tested package compared to the 
current package that has been around for decades or longer. Sounds like 
it may have been around since, well, Linux started, or whatever came 
before Linux itself.  New package, no idea when it was born but it seems 
to use Rust.

I very rarely post on -dev.  The news item at first sounded more like a 
announcement of a new package.  One that I might add, I don't see the 
need to switch to as the old package will still be there and is 
maintained to my understanding.  In reply to one of my posts, I was 
informed that it seems this new package could somehow break the commands 
the package I currently have installed provides, such as cp, ls and 
other important ones.  I find this confusing as heck.  If I don't 
install the new package, how is it going to possibly cause breakage of 
the package already installed?  Why can't the current package just be 
left alone and let those who want to switch deal with the change and 
whatever comes with it?

I'm thinking of masking the new version, currently keyworded, until this 
mess gets sorted out.  At this point, I'm confused and not sure what is 
going on and this is a critical package.  I've never seen a new package 
cause breakage if one doesn't install the new package. O_o

I'm going to include the original news item post for those who would 
like to read and reply but don't subscribe to -dev.  It will be below my 
usual good bye.

Anyone have a better understanding of this mess?  How can me not 
switching cause what I have currently installed to even possibly break?

I'm posting here so as to not clutter up -dev any more.  They got enough 
to deal with without me posting there to mostly get what is a user 
problem at this point.

Thanks.

Dale

:-)  :-)

News item posted on -dev:

On 3/20/26 2:35 PM, moltonel 3x Combo wrote:
> Hi,
>
> This news item can also be reviewed at
> https://github.com/gentoo/gentoo-news/pull/5
> The corresponding code PR is at https://codeberg.org/gentoo/gentoo/pulls/89
> This is my first time posting here and I'm not a Gentoo dev, apologies
> if I made mistakes.
>
>
> Title: Introduction of app-alternatives/coreutils
> Author: Vincent de Phily <[email protected]>
> Posted: 2026-03-04
> Revision: 1
> News-Item-Format: 2.0
>
> A new app-alternatives/coreutils ebuild is available, giving the
> choice between sys-apps/coreutils and sys-apps/uutils-coreutils as the
> main coreutils (mkdir, ls, etc) implementation. The default will
> remain the gnu implementation for the foreseeable future.
>
> The update should be transparent to most users, read on for further
> details.
>
> ## Choices
>
> If uutils-coreutils is available for your arch and profile, you
> can select it by setting `app-alternatives/coreutils -gnu uutils` in
> your packages.use.
>
> If you want to postpone or revert the transition, mask the
> corresponding ebuild versions:
>
> ```
>> =sys-apps/coreutils-9.10-r1
>> =sys-apps/uutils-coreutils-0.6.0-r1
> app-alternatives/coreutils
> ```
>
> ## Preparation and troubleshooting
>
> The new version of sys-apps/coreutils and sys-app/uutils-coreutils
> install their files with a prefix (`g` for gnu, and `uu-` for uutils).
> Afterwards, app-alternatives installs symlinks with standard names.
>
> Portage preserves some critical binaries, which will trigger a
> harmless file collision warning (assuming the default `protect-owned`
> portage feature is enabled) when app-alternatives/coreutils is
> installed for the first time.
>
> To reduce the window during which some utils will not be available at
> the standard location, make sure that app-alternatives/coreutils is
> merged straight after the new sys-apps/coreutils, by running
> `USE="gnu -uutils" emerge -v1 app-alternatives/coreutils` before
> updating the rest of the system.
>
> In the unlikely event of an incomplete update, keep in mind you can
> still use the prefixed names. If you somehow need to manually fix some
> symlinks, use the command below and consider reporting the issue:
>
> ```bash
> # Critical utils that portage should have preserved
> export U1="[ arch basename cat chgrp chmod chown cp date dirname echo env expr
>            false head hostname id install ln ls mkdir mkfifo mktemp mv printf
>            pwd readlink rm rmdir sleep sort stat tail test touch tr true uname
>            uniq whoami"
> # Utils that might be missing until app-alternative installs
> export U2="b2sum base32 base64 basenc chcon chroot cksum comm csplit cut dd
>            df dir dircolors du expand factor fmt fold hostid join kill link
>            logname mknod nice nl nohup nproc numfmt od paste pathchk pinky pr
>            printenv ptx realpath runcon seq shred sha1sum sha224sum sha256sum
>            sha384sum sha512sum shuf split stdbuf stty sum sync tac tee timeout
>            truncate tsort tty unexpand unlink users vdir wc who yes"
> for t in $U2; do
>   gtest -e /usr/bin/g$t -a ! -e /usr/bin/$t && gln -sf g$t /usr/bin/$t
>   gtest -e /bin/g$t -a ! -e /bin/$t && gln -sf g$t /bin/$t
> done
> ```
>
> The current implementation of app-alternatives/coreutils does not
> switch shell completions, so `cp` uses gnu completions, `uu-cp` uses
> uutils completions, and `gcp` does not complete. This will be
> addressed progressively, in collaboration with upstreams.
>
> ## Further reading
>
> [0] https://wiki.gentoo.org/wiki/Project:Base/Alternatives
> [1] https://www.gentoo.org/support/news-items/2022-12-27-alternatives-introduction.html
> [2] https://bugs.gentoo.org/961068
>