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

Ionen Wolkens <[email protected]> Sun, 22 Mar 2026 10:08:35 -0400

Newsgroups	gmane.linux.gentoo.devel
Message-ID	<ab_348VRBkuhg0R5@eversor>

On Sun, Mar 22, 2026 at 06:49:49PM +0500, Anna Vyalkova wrote:
> On 2026-03-22, Ulrich Müller wrote:
> >>>>>> On Fri, 20 Mar 2026, moltonel 3x Combo wrote:
> > 
> >> 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.
> > 
> > Maybe these are heretic questions, but:
> > 
> > 1. What problem does this solve?
> > 
> > 2. Why do we need app-alternatives here, instead of a simple virtual
> >    (plus a blocker)? I find renaming (e.g. gls, gcp) and symlinking
> >    of all standard tools incredibly ugly.
> 
> Not only ugly, but also potentially prone to file collisions. Although 
> currently (according to app-portage/pfl), only sys-fs/gdu::guru would 
> conflict with prefixed coreutils.

Now that you mention it, it does use up quite a bit of g* namespace
which afaik also isn't quite widespread/expected unlike e.g. gtar.
If really had to do this, it may(?) make more sense to do like ninja
did and do cp-reference and the like.

Admit that like ulm said, this all feels pretty ugly either way though.
I didn't think much of it when it's just a handful of tools, like ninja,
and tar. Plus for these, there is sometime a reason to call the original
tool because they don't aim for full compatibility, while uutils is not
supposed to need anyone to call a cp-reference because cp didn't work.

I forget what problems there may be with soft-blockers though, if any.

Without the whole symlink ordeal, there'd be no need for a news item
given nothing changes for regular users.
-- 
ionen

signature.asc (application/pgp-signature, 525 B)