public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin-apps@cygwin.com
Subject: Re: [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable
Date: Fri, 4 Nov 2022 20:27:51 +0100	[thread overview]
Message-ID: <Y2Vnt4lbKeDwYyO9@calimero.vinschen.de> (raw)
In-Reply-To: <cde96c9e-fafc-769d-d6a3-4375ed5fb1d6@SystematicSw.ab.ca>

On Nov  4 13:07, Brian Inglis wrote:
> On Thu, 03 Nov 2022 19:31:27 +0100, Achim Gratz wrote:
> > Brian Inglis writes:
> > > Suggest that I could come up with a package grep-nowarn which can only
> > > suppress the [ef]grep warnings, where the package would install
> > > [ef]grep-nowarn, and the postinstall script could rename the
> > > distributed shell scripts to [ef]grep-warn, and install alternatives
> > > with -warn priority 10, -nowarn priority 20; preremove would reverse
> > > the process.
> > > 
> > > Suggestions to accommodate -nowarn from grep package postinstall?
> > > I could supply the same postinstall and preremove as -nowarn to check
> > > for -nowarn and install or uninstall the alternative.
> > > 
> > > Sequence or timing issues to watch out for during postinstall/preremove?
> 
> > As Corinna already said, why GNU suddenly cares so much about strict
> > POSIX conformance in this case is puzzling.  If anything they should
> > have left the decision to packagers and IMNHO the warning should only be
> > presented when POSIXLY_CORRECT is set in the environment, if at all.
> > The patch to the wrapper script(s) in question is trivial and several
> > Linux distributions have removed the warning already (if you do this,
> > also change the interpreter from bash to dash).  Just skip any
> > extra packages and do the same.
> 
> The issue does not appear to be about POSIX compliance, but that [ef]grep
> were dropped from POSIX before 2008 and declared obsolescent, so the
> maintainers appear to be looking to drop those commands/scripts.

This is a usability issue.  If upstream thinks they have to do such a
potentially destructive and backward-incompatible change for no other
reason than "is not in POSIX", they can do so, but there's no good
reason the distros who *care* for usability have to do this either.

> 
> You could perhaps reach out to Eric Blake or Jim Meyering who are in the GNU
> grep contributor lists for rationale.
> 
> While Debian and OpenSuSE have reverted that change, Fedora has not in main
> or rawhide.

Right, Debian and OpenSuSE revert the change and the BSDs will not break
e/fgrep either, obviously.  I doubt Ubuntu will do that.  Fedora often
values progress, for a given value of "progress", higher than usability.
They will probably see lots of Bugzillas and user requests in other
forums due to this change and then ignore them.  But that doesn't mean
we have to do it.

Again: Egrep and fgrep are used in lots of scripts around the world.  A
change like this will have a massive impact for years to come.

So, again, in the name of usability, let's follow Debian and OpenSuSE
here, not Fedora, please.


Corinna

  reply	other threads:[~2022-11-04 19:27 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <announce.20220904140803.17862-1-Brian.Inglis@SystematicSW.ab.ca>
2022-09-29 18:55 ` Brian Inglis
2022-10-27 16:25   ` Corinna Vinschen
2022-10-28  6:49     ` Brian Inglis
2022-10-28  8:13       ` Corinna Vinschen
2022-10-28  8:20         ` Corinna Vinschen
2022-10-28 13:36           ` Thomas Wolff
2022-11-19 20:26             ` Brian Inglis
2022-10-28 12:40       ` gs-cygwin.com
2022-10-28 14:29         ` Corinna Vinschen
2022-11-03 18:08         ` Brian Inglis
2022-11-03 18:31           ` Achim Gratz
2022-11-04  0:09             ` Richard H. Gumpertz
2022-11-04 12:47             ` Corinna Vinschen
2022-11-04 19:07             ` Brian Inglis
2022-11-04 19:27               ` Corinna Vinschen [this message]
2022-11-13 17:09                 ` Thomas Wolff
2022-11-13 22:13                   ` Brian Inglis
2022-11-14  5:21                     ` Thomas Wolff
2022-11-13 21:06 Brian Inglis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y2Vnt4lbKeDwYyO9@calimero.vinschen.de \
    --to=corinna-cygwin@cygwin.com \
    --cc=cygwin-apps@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).