So Fedora 38 has chosen to break fgrep and egrep, to the fun of everyone who has them in scripts, especially scripts in crontab entries.

$ fgrep fred /dev/null
fgrep: warning: fgrep is obsolescent; using grep -F

Adding output to standard error is an *incompatible change*. And this is happening only because the GNU Grep people are <redacted because I cannot think of quite the right phrase>.

I have filed a Fedora 38 bug over this fgrep/egrep change and we'll see if it goes anywhere. I did my best to keep my system administrator's voice down, but I did not entirely succeed in hiding my views.

https://bugzilla.redhat.com/show_bug.cgi?id=2188430

2188430 – grep-3.8 is incompatible with previous versions of grep for fgrep and egrep

One of my opinions on egrep/fgrep versus 'grep -E' and 'grep -F' is that the former are rather nicer to type than the latter, and that matters. One extra letter, all lower case, no shifting needed. And egrep and fgrep have been there for a very long time.
Unsurprisingly, usage of egrep and fgrep is common across the shell scripts (and probably other things) that are shipped by assorted open source packages. GNU Grep's decision to loudly deprecate and then remove these names is a giant and pointless middle finger to the general free/open source ecology, one that will require hundreds of projects to undertake pointless work just because GNU Grep people want to get rid of 'redundant' commands that have been there since, oh, V7 Unix in the 70s.
@cks ehh. I see your point, the blast radius here is absolutely massive. On the other hand, this is such a tiny breakage, I have a hard time justifying calling this a "middle finger".

It's highly likely this is something distro packages aren't going to just spring on everyone. If they don't just decide to patch it in themselves to save themselves the trouble of fixing who knows how many downstream packages, then it's likely they'll save it for a major distro upgrade anyway, in which case admins usually have to expect verification for this kind of breakage anyway. I don't see it making huge waves.

@dead10ck Well, in actual practice Fedora dropped this change into a regular release with no particular notice and without auditing the shipped scripts and so on for egrep and fgrep usage. The breakage is not small in my sysadmin opinion, partly due to crontabs.

And GNU Grep is demanding every project in the world with shell code (or that exec things) audit it for fgrep/egrep usage, or else. That's not small.

@cks @dead10ck That's false. This change is only in grep 3.8. Fedora 37 has grep 3.7. 3.8 was first built for Rawhide last September, explicitly didn't go into the then-current F37 release, and waited to be included in F38 months later.
@carlwgeorge @dead10ck I was unclear in my post; by 'dropped this change into a regular release' I meant that they included it in a new Fedora release (F38) with no specific notice (and without fixing scripts from other packages, etc). Fedora X to X+1 is not in my mind a 'major distro upgrade'; barring things called out specifically in release notes, I expect it to be barely noticeable (and it usually is).

@cks @dead10ck It's probably fair that the Fedora maintainer could have considered a change proposal for this to raise visibility. It's just a deprecation warning, but I acknowledge the points you've raised about the ways it can have a outsized impact.

That said, Fedora X to X+1 is absolutely a major version upgrade. Fedora is known for innovation because every six months there is an opportunity for major changes. Maintainers don't have to wait years to deliver backwards-incompatible software.

@cks @dead10ck The reason it may not usually feel like a major upgrade going between versions is due to the outstanding QA work from folks like @adamw. The updates policy also guides maintainers to keep bigger changes in Rawhide only to sort out any kinks before going into a stable Fedora release (where updates are actually quite a bit more conservative).