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

On 3/23/26 6:53 AM, moltonel 3x Combo wrote:
> On Mon, 23 Mar 2026 at 01:48, Eli Schwartz <[email protected]> wrote:
>> This would be the fourth time we add app-alternatives packages. And the
>> *first* time that we create a news item for it at all, let alone
>> specifically create a news item not to tell people the app-alternatives
>> exists, but try to advise them how to edit a USE flag.
>>
>> It is genuinely unprecedented.
> 
> Let's see how https://codeberg.org/gentoo/gentoo/pulls/89#issuecomment-11950407
> pans out. Maybe we can then decide that no news item is needed at all.
> 
>> No, the link you offer is *not* doing what you say it is doing.
> 
> Not sure what link you're talking about here.



You've consistently seemed to claim that Gentoo does news items "for new
app-alternatives", e.g.


"""
it's
worth mentioning the upcoming file collision warning ***and how to
actually switch if people are interested, like we did for previous
app-alternative ebuilds.***
"""

(emphasis mine) which is what I directly reply to here,


and originally linked to

https://www.gentoo.org/support/news-items/2022-12-27-alternatives-introduction.html

Which was actually the only time we ever mentioned app-alternatives in
the news, per git log -p.

This previous case only listed one "how to switch" for all 9 packages,
and did so using the language "for example", and with the explicit goal
of describing the fundamental approach one would use to *port* their
system config from explicit eselect of nondefault choices, to
package.use selection of nondefault choices.

i.e. it was never about telling people an app-alternatives existed, it
was about alerting users of eselect that they need to migrate their
system settings from one scheme to another, and providing an on-ramp
tutorial for app-eselect as nobody ever heard of it before.

For gpg, lzip, ninja -- we didn't have news items. They weren't expected
to break, nor was it necessary to tell users of them how alternatives
work, because everyone is now expected to know.


>> If it's just a USE flag why do we need a news item to explain it?
> 
> I find the fixation about documenting the USE flag a bit weird. I've
> stated many times that the main purpose of the news item is
> troubleshooting. It's definitely not about advocating for uutils, if I
> was writing the news item in a more opinionated tone, I would
> recommend users to stick with gnu.
> 
> The opt-in instructions are just in-passing, just 3 lines out of 79.
> You wouldn't write a news item just for that, but it's IMHO in-topic
> there. I feel your resistance to documenting the opt-in is less about
> the news-worthyness and more about preventing uutils from gaining
> traction.


I assure you I'm not shy to say yes, I do believe adding 50% cognitive
overhead for "as a user what does this mean I need to do" via 4%
additional lines, is still an impactful reason to debate the validity of
a notification seen by 100% of users.

You need not dress it up by claiming its # of lines is so few.

The fact that it then confuses users into thinking they might "need" to
switch is just making it worse. It is not my primary objection.
Nonetheless, allow me to make my opinion bulletproof clear:

uutils is technical trash and introduces security vulnerabilities, bugs,
etc. Nobody should use it, but Gentoo is about choice, including the
choice to break your system or be insecure.

i am fiercely opposed to utilizing a news item to *en passant* cause it
to gain undeserved traction, yes.


>> But completions work fine? Why should I, or anyone, care that
>> completions for newly created binaries that exist for internal
>> implementation details of how app-alternatives provides switchable
>> symlinks, don't get completed?
> 
> They work ok, but the ones from bash-completion are not as good as the
> ones from uutils. For example, they only complete --long-options for
> many utils, like `cut`. A user having experienced the uutils
> completion might be disappointed by the system-wide ones.
> 
> I agree that this is only a tangential remark, I don't mind deleting it.


Report it as a bug to the bash-completions project, don't write a
section in a news item for something that is not even changing.

Note bash-completion doesn't allow installing your own completion here.
It is defined at startup in /usr/share/bash-completion/bash_completion
and not via complete -D's processing of _comp_load picking up dropin
files for commands with no completion after shell init is done.

It works by parsing --help.


>> ... obviously I don't feel the way you do or I wouldn't object that the
>> news item needs changing in order to do so.
>>
>> Please elaborate why you feel that this proposed news item already
>> "essentially" only explains how to be careful in emerge -uDN @world to
>> migrate defaults+oldrepo --> defaults+newrepo, given it is full of
>> information about "choices"?
> 
> 1-5: metadata
> 7-13: introduction
> 17-19: uutils opt-in
> 21-28: delaying the update
> 32-39: describe failure mode
> 41-45: simple issue avoidance
> 47-68: fixing bigger breakage
> 70-73: describe gotcha


not a gotcha


> 77-79: Further reading
> 
> By my count, about 2/3rd of this text is about potential issues and
> fixes. 4% is about the opt-in.


10, 15-28, 70-73: describing choices (15 makes this obvious, no?), not
"potential issues and fixes".


-- 
Eli Schwartz

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

wnsEABYIACMWIQTnFNnmK0TPZHnXm3qEp9ErcA0vVwUCacFG2wUDAAAAAAAKCRCEp9ErcA0vV9aM
APwO5VbCQj6G1WB6XN3iu9uMtWXZw3QW6UdlLQAZtVZyVgEA05X4RhnfDWuXVrB+cYOL1KK1sfzR
41e0scEP0k2F7gk=
=5Yyp
-----END PGP SIGNATURE-----