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

Ionen Wolkens <[email protected]> Mon, 23 Mar 2026 12:00:24 -0400
Newsgroups	gmane.linux.gentoo.devel
Message-ID	<acFjmD-HcNZDbp60@eversor>
On Mon, Mar 23, 2026 at 11:42:20AM -0400, Ionen Wolkens wrote:
> On Mon, Mar 23, 2026 at 11:35:31AM -0400, Eli Schwartz wrote:
> > 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
> 
> Can't we just have uutils RDEPEND on coreutils when -native-symlinks,
> which makes portage emerge coreutils first before uutils is rebuilt.
> And collisions should be ignored with the soft-blockers.

Well, not sure if we even need RDEPEND. virtual/coreutils would be in
@system and need to be satisfied. Portage may just force-schedule
sys-apps/coreutils first either way (if not, we can try RDEPEND --
do believe we can get this to work one way or another but I haven't
experimented).

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



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