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

Ionen Wolkens <[email protected]> Sun, 22 Mar 2026 10:35:43 -0400
Newsgroups	gmane.linux.gentoo.devel
Message-ID	<ab_-P0GFVQDFuQo8@eversor>
On Sun, Mar 22, 2026 at 10:08:35AM -0400, Ionen Wolkens wrote:
> 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.

..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 forget what problems there may be with soft-blockers though, if any.

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

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

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