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

On Mon, 23 Mar 2026 at 14:14, Ulrich Müller <[email protected]> wrote:
> For the record, I am strongly opposed to the app-alternatives variant.
> It comes with some cost (however little) for the vast majority of users,
> just for slightly more convenient use of what at this point I would
> consider a niche application. And as was said before, we can revisit
> the issue in future.
>
> Can you elaborate what the "switching pain" would be with a virtual?
> Because a USE flag (or even two IIUC) would also be needed for
> app-alternatives. Also, how often do you expect users to switch?

I agree that it is a niche usecase, one that I wouldn't generally
recommend. But there is demand, anecdotaly I've seen a lot of people
wondering about or attempting it. Last September after reading the
corresponding bugtracker discussion I thought "how hard could it be ?"
and here we are today, still gathering interest.

I don't see the point of committing an unsatisfactory version to
revisit later. We can get it right the first time, there is no rush.
And to be clear: IMHO getting it right includes being able to
co-install.

AFAIU, switching using a virtual would require
* Switching USE flags on the two coreutils packages
* A reemerge of FooUtils to disown the unprefixed binaries/symlinks
  Using the UNINSTALL_IGNORE+pkg_postint trick to avoid breaking the system
* An emerge of BarUtils to own the unprefixed binaries/symlinks
  Dutifully ignoring the file collision warning
* A few minutes of compilation each time
* More complex logic in both coreutil ebuilds
* Even users never switching will need a one-off recompile of gnu coreutils

In contrast, switching using app-alternatives requires a one-time
recompile of coreutils, and then a single USE flag change and a 10sec
reemerge of app-alternatives.

For a user who doesn't care about uutils, the pain is the same with
both solutions (you still need a recompile). For somebody wanting to
switch (I do expect some people will try uutils and then revert), the
difference is strong.

App-alternative works fine, it's designed for this, and has been
recommended to me as the solution. Do you have something to say
against the other uses of app-alternative in the tree ? I don't see
what's different here.