On Fri, 2022-09-09 at 11:41:49 -0500, Paul Eggert wrote: > On 9/9/22 07:16, Guillem Jover wrote: > > There are now packages that fail to work such as > > apt-file (https://bugs.debian.org/1019329), > > From what I can see, that bug report doesn't say that apt-file fails to > work, only that apt-file issues a warning and then goes on to work.
Ah, you are right, that might have coincided with a query I did that returned nothing then, sorry about that! > > Transitioning away from fgrep/egrep seems like it would be painful as > > that involves lots of upstream projects: > > I glanced at those, and didn't see any projects that will stop working, only > projects that will see annoying warnings. Admittedly I didn't look at all > the examples, but in the first page of > <https://codesearch.debian.net/search?q=fgrep&literal=1> (your first > citation) all the code examples should continue to work. > > Could you give examples of programs that actually stop working? That would > help us consider remedies. It's true that most of those instances are probably not going to fail. But what is definitely being affected are autopkgtests from Debian packages for example. By default those consider any output to stderr a signal to mark the test as failing. So the new grep failures are causing unrelated tests to fail now. Some are going to be hard to fix locally, or quickly everywhere, for example the one in libtool, as until it is fixed, relibtoolizing will have not effect, and afterwards that will get fixed only as long as the packaging always forcibly relibtoolizes (or autoreconfigures). <https://bugs.debian.org/1019725> As I've mentioned earlier, personally, I definitely want to be able to see those kinds of warnings so that I can fix or change stuff I maintain, or report bugs with patches. But unfortunately it seems this is causing enough disruption that all the new warnings might end up being disabled in Debian. I think it's been discussed earlier that environment variables are not desired? But I think it would still be nice to be able to control those warnings globally/externally, so that even if say a project like Debian ends up disabling them, people can still enable them to be able to diagnose and track those down. Thanks, Guillem
