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

Ionen Wolkens <[email protected]> Sun, 22 Mar 2026 19:22:35 -0400
Newsgroups	gmane.linux.gentoo.devel
Message-ID	<acB5u2f15XB7CvYM@eversor>
On Sun, Mar 22, 2026 at 06:26:33PM +0000, moltonel 3x Combo wrote:
> On Sun, 22 Mar 2026 at 14:36, Ionen Wolkens <[email protected]> wrote:
> > ..not to say it couldn't happen if they start to diverge someday, or
> > lag behind. Not that these tools are meant to be all that complicated,
> > so I'm not too worried -- could be revisited if really necessary rather
> > than preemptively.
> >
> > If there is tools only provided by one but not the other (not checked),
> > coreutils could potentially have a USE to skip common ones and depend
> > on uutils to provide them.
> 
> I wouldn't be too worried here, uutils takes drop-in compatibility
> with gnu very seriously. FWIW, my initial draft of the
> app-alternatives ebuild had to deal with tools available in one but
> not the others (uutils provides more hash algorithms and can build
> them as standalone tools), but uutils-0.5.0 fixed that discrepancy.
> 
> > ...but that remains assuming that there is no issues. Tools do need
> > to not go missing mid-merge, albeit the way portage operates with
> > soft-blockers I don't think there should be? (it just ignores
> > collisions rather than remove them)
> 
> Note the current ebuilds make extensive use of UNINSTALL_IGNORE to
> deal with the catch-22, but I'm going to try a hybrid approach with
> pkg_postinst which should work better.
> 
> > > Without the whole symlink ordeal, there'd be no need for a news item
> > > given nothing changes for regular users.
> >
> > Or at best could inform only those with uutils-coreutils installed
> > if really want to, as it'd only concern them without the symlinks.
> 
> The whole point of app-alternatives is to manage symlinks, I'm not
> sure what "without the symlinks" hypothetical universe you're talking
> about.

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.

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.

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.

Similar to how we handled virtual/zlib where when zlib-ng is emerged
with USE=compat, it replaces the original sys-libs/zlib.

In this context, *nothing* changes for users of the original coreutils,
and so there is nothing that needs a warning -- while uusers of
uutils-coreutils have a way to start using it as system coreutils, just
not keep both installed at same time.
-- 
ionen
signature.asc (application/pgp-signature, 525 B)