On Thu, Sep 15, 2022 at 9:28 PM Guillem Jover <guil...@debian.org> wrote: > 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 for the feedback. We may make a new release with two additions: - an envvar to control [ef]grep warnings, enabled by default - a configure-time option to make it disabled by default This would be an envvar for which we do not commit to any level of support in future releases.
