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

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.