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

On Mon, Mar 23, 2026 at 09:27:19AM +0000, moltonel 3x Combo wrote:
> 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.

Like noted in another mail they can coexist one way just fine. Not
as convenient as app-alternatives but I think there's just a fair
amount of opposition to the idea of changing the original coreutils
over this. This could be revisited in the future if we feel it is
really needed but at this stage I'd (personally) rather a less
invasive alternative that'd also need no news item.

> 
> 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
> 

-- 
ionen

-----BEGIN PGP SIGNATURE-----

iQFPBAABCAA5FiEEx3SLh1HBoPy/yLVYskQGsLCsQzQFAmnBGmwbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyAAoJELJEBrCwrEM0fy4H/iC806p8hN76AG7baJmJ
fIGHRp6fZxmJ+UloHXZqcwwpTr1K6ur51NMjaqUeKZPnyUtzrMlq6bpOqAW52X/w
zs2odG4O9Uq6j9yRmYNQalwscFFl44t/+8EzUfgkQYope5p7MMhyxcXCxWhdmkjv
vd9MYj5+2OKlNH3DoldpX3Iciu23xHk6egVW8h3dIgOmiUvVLEA44Ic9er0H+fed
qE4GMZ80UzpO9pgwXuIK5jX+9G2n+m+4maFH/c+BvP2YrhEbI9ei16xjUtWh5Tr8
MPGNSaqJHjuhOYuycM8nGLq436ec1jQ+cbCAFauGXofiOk0lDXRnCeKnd87a3QVx
e3o=
=NrHR
-----END PGP SIGNATURE-----