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

Sorry, I sent that reply off-list by mistake.

On Tue, 24 Mar 2026 at 13:23, moltonel 3x Combo <[email protected]> wrote:
>
> On Tue, 24 Mar 2026 at 08:31, Arthur Zamarin <[email protected]> wrote:
> > * This is very risky change for users, which can break the system during
> > upgrade,
>
> This was the reason for the news item. Having extensively tested it
> and improved it over time, I actually think the risk and danger are
> both low. But it's a critical package, which deserves extra care.
>
> Again: I have a change planned which should make the upgrade much
> cleaner/safer, in line with other app-alternative ebuilds.
>
> > but even if not, can break any random stuff somewhere in the
> > system, and it would be too hard to detect and debug. We Gentoo devs
> > already know that random upstream sometimes use obscure features without
> > any reason, and I'm sure someone uses some random feature of coreuils
> > that uutils won't implement exactly (they already declared as such for
> > some random rare stuff).
>
> Yes, compatibility keeps increasing, which means it's not 100% yet.
> That said, I've been testing uutils on two systems since uutils-0.4.0
> (which claimed 85% compatibility, compared with 96% for 0.7.0) and the
> only issue I encountered was the install-xattr bug. There's always
> that one weird cornercase, but it's slowly becoming just as likely to
> hit a gnu bug as a uutils one.
>
> > * We must have a way to see the fact a user modified with uutils his
> > system. Print in someway that can be easily seen that it was done. I
> > also acknowledge that most likely, various devs will just ignore such
> > bug reports because they don't care about uutils (in similar ways like
> > bugs on arch level, musl, llvm and similar are many times handled).
>
> That'd be USE="-gnu uutils" in `emerge --info` ?

Actually that's not good enough, because that USE might not be set
globally. How about showing (still in `emerge --info`) the version
string of /usr/bin/install ? I'll send a patch for that.

> > * The News Item gives an advertisement in a place a silent experiment is
> > happening. I think most of us prefer users don't migrate to uutils *for
> > now* (who knows what the future holds, but let's not be hasty).
>
> I was trying to be very neutral and some people saw an advertisement.
> FWIW, I wouldn't recommend the switch for most systems today. But I
> have hope for the future, and I think now is a good time to offer the
> choice.
>
> > * I think we should at least mask the possibility of migrating behind a
> > use.mask, until further tests are done by various devs, some users, and
> > maybe one tinderbox run. A use.mask is a really good way to warn the
> > user, and make him understand he goes into YOLO territory.
>
> I'd be happy to use.mask uutils initially. It's something I had
> suggested in the code PR, but didn't get a reply. Note that it's
> already masked for wd40, split-usr, and all but 3 arches.
>
> > * Security wise, I think the claims of safer because Rust is bogus. Rust
> > helps mainly with memory issues, but does nothing for logic ones. With
> > coreutils, I don't think memory issues were often or something, but
> > rather the logic ones where the "common" (I mean common by the percent
> > from total CVEs, not that it happens common time-wise). The latest CVEs
> > for uutils confirm it, and remember, it wasn't audited by the same scale.
>
> Everything else being equal, Rust *is* safer than C. Not only because
> of memory safety (though it's a big part and frees time for other
> aspects), but the language does have less hidden state and behaviours,
> enable and encourage APIs that are harder to get wrong (see Result or
> Mutex), and yes can even help with some logic bugs (see typestate or
> zero-size tokens).
>
> Of course that doesn't make *uutils* safer than gnu. Coreutils are
> more complicated than one might think, and there are countless ways to
> screw things up, whether Rust helps or not. I'm sure uutils is buggier
> than gnu at this stage. But it's improving fast, and its tests are a
> superset of gnu's. It'll earn trust in due time.
>
> With all that said, we're not making the uutils vs gnu judgement call
> here, but enabling users to do their own. Gnu isn't perfect, and CVEs
> isn't the only criteria.
>
> > In total I see no reason for a News Item, or making the migration
> > without a mask, and if we go with it, we must add a clear way to notify
> > the build log the system is "special".
>
> Looking forward to dropping the need for a news item, and I'll also
> use.mask. If `emerge --info` isn't enough already, tell me what would
> be.
>
> Thanks for the review.