bug#57604: [ef]grep usage -> POSIXLY_CORRECT?

[Jim Meyering]

On Thu, Sep 15, 2022 at 9:28 PM Guillem Jover <guillem@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.