Re: Re: news item: Introduction of app-alternatives/coreutils

On Sun, 22 Mar 2026 at 23:23, Ionen Wolkens <[email protected]> wrote:
> It's been removed from quotes, but this whole thread was a reply to
> ulm suggesting an alternate option *without* app-alternatives.
>
> Aka instead have a virtual/coreutils where the two packages block
> each others to allow using uutils-coreutils as the system coreutils.

Ah, fair enough, sorry for the confusion.

> Meaning no symlinks, or at least none in the sense of cp-reference or
> gcp that would be shared between the two to allow being installed at
> same time.
>
> This what I meant when I said that unlike e.g. ninja-reference or gtar
> (which are quite different than samurai or bsdtar), there should be
> little need for a package to depend on the original coreutils just
> so they can call cp-reference for a feature that uutils does not have.
> Meaning that coexisting shouldn't be essential.

I can appreciate that argument. Makes more sense than arguing that
none of the possible prefixes for gnu utils would be distinctive
enough.

> If e.g. you install uutils-coreutils with USE=native-symlinks or
> something, it would *overwrite* bin/cp and tell portage to unmerge
> sys-apps/coreutils in the process rather than let it coexist.

I really want to let the two coexist though. It's possible with a
virtual, a USE=symlink, and some require/block logic, but that comes
with more switching pain. At this stage it's IMHO better to use
app-alternatives, which is specially designed for this.

Note that there seems to be a way to improve the PR and reduce the
"damaged system window" to almost nothing. I'll work on that before
posting a new iteration of the news item.

https://codeberg.org/gentoo/gentoo/pulls/89#issuecomment-11950407