Re: Question about -dev thread "Introduction of app-alternatives/coreutils"

Nuno Silva <[email protected]> Thu, 26 Mar 2026 09:18:14 +0000
Newsgroups gmane.linux.gentoo.user
Message-ID <[email protected]>
On 2026-03-24, Michael wrote:

> On Tuesday, 24 March 2026 07:23:03 Greenwich Mean Time Dale wrote:
>> On 3/24/26 2:13 AM, Ionen Wolkens wrote:
>> > On Tue, Mar 24, 2026 at 01:48:55AM -0500, Dale wrote:
>> >> On 3/24/26 1:08 AM, Alexis wrote:
>> >>> which comes across to me as implying that the contributor's
>> >>> proposal
>> >>> _would_ cause breakage, regardless of whether people wanted to
>> >>> switch
>> >>> to using uutils or not.
>> >>> 
>> >>> 
>> >>> Alexis.
>> >>> 
>> >>> [a]
>> >>> https://archives.gentoo.org/gentoo-dev/CANQow5KPWC6bt0yg7QXw_xwKCY
>> >>> [email protected]/>> 
>> >> That is what I still can't figure out.  Why is a new package going
>> >> to break a old package when the new package isn't installed??
>> > 
>> > Because it needs to change how the old package is installed for the
>> > new package to be installable in its current state -- which is part
>> > of the reason many developers are opposed to it.
>> > 
>> > In theory it*shouldn't* cause problems but there can be edge cases
>> > depending on how users are using the package, and it was debated
>> > whether the news item is needed or not "just in case". The average
>> > user would likely be entirely unaffected beside possibly being
>> > surprised by the changes and wondering what happened without a news
>> > item.
>> 
>> Ohhhh.  So my current package would change so that the other package
>> could be installed too.  I kinda get that.  Given the old package has
>> such a long history, I'd argue the new package needs to deal with it's
>> own thing and not interfere with the old package, installed or not.
>> Basically, the new kid on the block has to prevent breakage if it is
>> used.
>> 
>> The bad part of this, the package in question is so critical.  A
>> system can't run without those commands.  Messing with that should
>> only be done if it is absolutely necessary.  Basically no other
>> option.  Yea, I'm not liking that idea.  I understand it better but
>> still, it needs a better plan.
>> 
>> Thanks for explaining.  This helps and prevented clutter on -dev as
>> well.
>> 
>> Dale
>> 
>> :-)  :-)
>
> Is this uutils adoption being pushed by Canonical?  I've read bug 
> 961068, but other than an unqualified claim of better system security by 
> a passer by, I don't understand why Gentoo is considering its 
> introduction.  Is the aim of the uutils project "... to be able to use 
> the same utils on Linux, macOS, Windows and other platforms" or to 

As far as *code* portability is concerned, doesn't GNU coreutils already
allow compilation for other platforms? (As for interface and behaviour
portability, it's possibly more relevant to follow the spec than it is
to have the same utilities on all platforms?)

> ensure "... that scripts can be easily transferred between platforms" 
> something Gentoo devs want to spend their time on?

Introducing one more implementation of these utilities doesn't mean
portability is magically achieved, it rather means there's one more
implementation to consider when analysing portability, and which may
even introduce more incompatibilities to consider (see
e.g. https://xkcd.com/927/ ).


(Also, how portable are Rust build tools? Is this something which could
be built on e.g. an Intel Pentium, with the small amount of memory such
machines usually appeared with, or on Gentoo running on a Powerbook G4?
(Honest question, I still don't know much about the Rust world.))

-- 
Nuno Silva