grep 3.6 update is a downgrade to grep 3.0

[class101]

grep 3.6 update is a downgrade to grep 3.0

Describe the issue

When I update MSYS2, I'm presented an update that is in reality a downgrade of grep to version 3.0

Package (13)                                Old Version     New Version
msys/grep                                   3.6-1           1~3.0-3

Steps to Reproduce the Problem

1. Install grep 3.6-1 pacman -U grep-3.6-1-x86_64.pkg.tar.zst
2. Update MSYS2 pacman -Su
3. You get prompted that a new version 1~3.0-3 is available
4. I expect to get a version higher than 3.6-1

Additional Context: Operating System, Screenshots

Output of grep --version with grep-1~3.0-3

> grep --version
grep (GNU grep) 3.0
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Output of grep --version with grep-3.6-1

> grep --version
grep (GNU grep) 3.6
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Mike Haertel and others; see
<https://git.sv.gnu.org/cgit/grep.git/tree/AUTHORS>.

[1480c1]

grep > 3.0 breaks a lot of existing things such as compilers and libraries

ref https://github.com/msys2/MINGW-packages/issues/9771

[class101]

Original issue is quickly closed imo, downgrading to grep 3.0 should be considered a temporary solution

grep is my most used tool whether I'm on Windows or Linux.

I'm not affected by the issue and I find this is a pity to downgrade grep just because a part of users can't get things working as before.

It just lacks a patch and issue should be reopened

[Alexpux]

@class101 it's not that some users have something broken. Grep > 3.0 broke compiler totally. Feel free to reimplement dropped features in grep and provide a patch

[piotrvv]

Add an alternative instead of grep use ugrep in PKGBUILD MSYS-packages. When you do this, use utf by default in python. All packages from msys pakages will need to be rebuilt. In mintty you have everything in utf but the default output for python is ansii. And python does not distinguish between upper and lower case letters like in linux, but only does everything like in windows. Add the missing patch files from cygwin to python.

[piotrvv]

Rebuild gcc-10.2.0 from msys. With such check results. 😎 configure: Support for IEEE modules: yes checking POSIX version of getpwuid_r with 5 arguments... yes checking whether the target supports hidden visibility... yes checking whether the target supports symbol aliases... yes checking whether the target supports __atomic_fetch_add... yes checking whether pragma weak works... yes checking whether the target supports weakref... yes checking whether the target can unlink an open file... yes checking whether the target has CRLF as line terminator... no configure: updating cache ./config.cache checking that generated files are newer than configure... done

[Alexpux]

@piotrvv what you want to say with this? Grep broke MINGW compilers, not MSYS. You will be able to build compiler but it broken. Read carefully issues that we point

[piotrvv]

I guess we are dealing with a problem in msys grep. At the end of the line. Which causes problems when building in mingw. I don't think this is just a problem of the mingw themselves. The suggestion is to compare the outputs of grep and ugrep.

[Alexpux]

@piotrvv during build MINGW compiler we always use MSYS tools

[piotrvv]

I know you use them. But I think a lot of collaboration problems are posed by the grep itself in the msys packages. When you use grep and ugrep you will see for yourself how many problems there are with the msys2. Utf and ascii are mixed up in many places and the end of the windows and linux lines are a big contributor to the problems of grep itself. Msys packages has python in ascii mode by default.

[piotrvv]

ugrep keeps telling me i have an asci line, but the mintty terminal still turns utf. When you build the package in msys tool mintty it sees utf but grep goes silly. For the msys packages, it's best to move everything to utf in mintty.

[piotrvv]

Sync lines to utf in python perl ruby on the output in the mintty terminal

[piotrvv]

You build packages in msys tools but will forget about the default package options in msys packages.

[piotrvv]

By default, msys packages uses 3 different default languages.

[Alexpux]

@piotrvv I don't understand what you mean. Problem with grep is that it not properly parse output from any native Windows application because grep>3.0 doesn't properly handle /r/n line endings

[piotrvv]

Perl has an output in a utf terminal by default. Python defaults to ascii. Ruby has a different default language by default. Try to check something with grep.

[piotrvv]

You need to synchronize the default languages in ruby and python perl. Because minty will display them but grep will have problems with mixing different default languages on output.

[piotrvv]

Due to the lack of synchronization of these languages, you have problems when autootols does something. Meson and pacman dont understand.

[piotrvv]

Due to the default different languages in mintty we have a compilation problem. "checking whether the C locale is free of encoding errors...no"

[Alexpux]

@piotrvv i don't mind about this tools. Concrete mingw GCC commands output parsing wrong. Please read all bug reports about this issue before next discuss.

[piotrvv]

I have your msys-tools on my server and they are following the changes. I have a terminal in many places I see problems with proper encoding in the terminal line. You forget about the correct language settings in many packages.

[Alexpux]

@piotrvv original issue is not about encoding, but encoding problem maybe as separate issue

[rubyFeedback]

Alexpux wrote:

@class101 it's not that some users have something broken. Grep > 3.0 broke compiler totally.

Except that grep works fine on e. g. my Linux box where I compile most things from source as-is.

This is more a problem of the msys toolset that should be fixed rather than insinuate that "grep broke xyz". It should be acknowledged as a bug in the msys ecosystem rather than attempt to reframe it and blame it on the grep authors. Even aside from that class101's report is still correct since users did not expect a sneaky downgrade. At which point did pacman decide to override the user's command?

[Alexpux]

@rubyFeedback if you want new version of grep, you can create your own package, for example grep-new, that replace grep. It will be not overwrites by pacman. Your point that this is MSYS issue maybe true, but for this years no one fix it and I'm currently not active developer anymore. So you can wait that someone fix it or try to fix yourself - this is opensource.

[mati865]

This is more a problem of the msys toolset that should be fixed rather than insinuate that "grep broke xyz". It should be acknowledged as a bug in the msys ecosystem rather than attempt to reframe it and blame it on the grep authors.

If you can fix it either within grep or autotools (this is where this bug manifests) we would really appericate. We don't have knowledge nor time to take care of it. From our point of view its grep bug because using old versions creates working packages and upgrading grep breaks them. It could be entrirely true this is autotools or Cygwin bug that we happen to avoid using older grep but as I already said we don't have resources to investigate it deeply.

Except that grep works fine on e. g. my Linux box where I compile most things from source as-is.

Except Linux uses sane defaults for the text files, this is not the case on Windows hoverver.

Even aside from that class101's report is still correct since users did not expect a sneaky downgrade.

So what were we supposed to do, keep latest grep version and stop building updates for most of the packages because the compiler is broken?

At which point did pacman decide to override the user's command?

It never did. To downgrade package you have to use pacman -Suu.

Aside from that anyone can use native grep from mingw/ucrt/clang repositories which is much newer.

[class101]

From our point of view its grep bug because using old versions creates working packages and upgrading grep breaks them.

I don't think this reason is 100% valid.

For example, we recently upgraded a project from jdk8 to jdk11.

It worked fine under 8, but some features broke in 11, this does not mean 11 is bugged.

[Alexpux]

@class101 You and others don't hear what we tell. If we will update grep than we cannot build properly GCC toolchains for MINGW packages. Mingw toolchain builded with latest grep is not workable. Do you understands?

Without properly working GCC we cannot build other packages. So this is critical issue with grep and we will not update grep while there are no solution

[jeremyd2019]

From our point of view its grep bug because using old versions creates working packages and upgrading grep breaks them.

I don't think this reason is 100% valid.

For example, we recently upgraded a project from jdk8 to jdk11.

It worked fine under 8, but some features broke in 11, this does not mean 11 is bugged.

But, if you had some dependency that didn't work under 11 but did under 8, you might reasonably hold off on updating to 11 until the dependency is updated to support it. This is the situation with autotools working under grep 3.0 but not 3.6.