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

Ionen Wolkens <[email protected]> Mon, 23 Mar 2026 12:20:03 -0400
Newsgroups	gmane.linux.gentoo.devel
Message-ID	<acFoMwf2TS087Bzk@eversor>
On Mon, Mar 23, 2026 at 12:00:24PM -0400, Ionen Wolkens wrote:
> 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).

..then again, maybe this could allow the PM to schedule after.
RDEPEND may be more definite.

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



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