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

On 3/22/26 10:32 AM, Ulrich Müller wrote:
>>>>>> On Sun, 22 Mar 2026, moltonel 3x Combo wrote:
> 
> [Why have you dropped gentoo-dev from CC?]
> 
>>> 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.
> 
>> The main argument against virtual+blocker is that we want to keep both
>> packages co-installable.
> 
> Entirely possible with a virtual. Have uu-coreutils install the programs
> with prefixed names, and only install the generic names with some USE
> flag. That same flag would also be a USE-conditional for the blocker
> against coreutils.


I am skeptical that this would work. Normally, blockers function by
installing package cat/a which blocks the previously installed cat/b.
So, a gets installed and then only afterwards b gets uninstalled, and
a's files overwrite b's files which is fine because b is after all
getting uninstalled and the PM is permitted to ignore collisions in this
case.

b's files never actually disappear. At any given time either a or b must
be installed to provide the overlapping files.

If we did this via USE blockers, then uutils could be rebuilt with
USE="-native-symlinks" or whatever, *before* sys-apps/coreutils gets
installed. This then breaks the system because no critical system
binaries are available. Using the virtual does not, in the end, solve
anything (unless they are treated as fully incompatible blocking
packages), because there are transition states where the only package
that is installed has broken USE. It might work one-way if coreutils is
*fully* blocked by uutils[native-symlinks] but then you likely can't
safely switch back.

I seem to recall that portage has known buggy handling of this. In fact
the only real solution is to rebuild coreutils ("package a") and have it
overwrite uutils' symlinks, and then only afterwards rebuild uutils
("only afterwards package b gets uninstalled"), and ignore ALL file
conflicts between the two. And then... what? Check after the fact and
report an error? Real solution or not, the *correct* solution is to know
when installing one package, what files the other package would
eventually install, which presumes that binaries are used, which is why
binary-only distros can avoid this problem.

tl;dr

app-alternatives is correct here.



-- 
Eli Schwartz

-----BEGIN PGP SIGNATURE-----

wnsEABYIACMWIQTnFNnmK0TPZHnXm3qEp9ErcA0vVwUCacFdwwUDAAAAAAAKCRCEp9ErcA0vVw9Q
AP97YlRPySBr1OVWeB3yOXoY3EYnSkQNrmZIXm8C5jWOPAD/RBELcIXO2F695r34FqvplUWh2GIn
B1UFHj2oSqm4NAI=
=mMyz
-----END PGP SIGNATURE-----