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

Ionen Wolkens <[email protected]> Sun, 22 Mar 2026 19:28:40 -0400
Newsgroups	gmane.linux.gentoo.devel
Message-ID	<acB7KEPknBeVOpoU@eversor>
On Sun, Mar 22, 2026 at 07:22:35PM -0400, Ionen Wolkens wrote:
> 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,

Well, nothing beside needing a virtual installed anyway, this may
make them curious at best but it's nothing that can break their system
or need any sort of attention.

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