MSYS2-packages icon indicating copy to clipboard operation
MSYS2-packages copied to clipboard

Add warning to makepkg-mingw if mingw-w64-file/grep/sed are installed

Open cyrilarnould opened this issue 2 years ago • 7 comments

Following the discussion in #14313, I've tried to implement a check in makepkg-mingw to remediate the issue a little bit.

Unfortunately, the pacman -Q query takes around 1.1 seconds (at least on my machine), I couldn't find a faster way to implement this however.

cyrilarnould avatar May 21 '23 15:05 cyrilarnould

Isn't it possible to check if the executable exists? For example, $MINGW_PREFIX/bin/file.exe.

Biswa96 avatar May 21 '23 15:05 Biswa96

Yep, that seems like a better solution. I'll update the pull request.

cyrilarnould avatar May 21 '23 15:05 cyrilarnould

do we have some specific evidence for each tool breaking something? Just so we have it documented somewhere.

lazka avatar May 23 '23 07:05 lazka

do we have some specific evidence for each tool breaking something?

This does not look something is breaking but suspicious. Here is a message while using ucrt64 file packaage.

==> Extracting sources...
Usage: F:\msys64\ucrt64\bin\file.exe [-bcCdEiklNnprsSvzZ0] [--apple] [--extension] [--mime-encoding]
            [--mime-type] [-e <testname>] [-F <separator>]  [-f <namefile>]
            [-m <magicfiles>] [-P <parameter=value>] [--exclude-quiet]
            <file> ...
       F:\msys64\ucrt64\bin\file.exe -C [-m <magicfiles>]
       F:\msys64\ucrt64\bin\file.exe [--help]

Biswa96 avatar May 23 '23 13:05 Biswa96

do we have some specific evidence for each tool breaking something? Just so we have it documented somewhere.

There's the discussion in #14313 which provides some examples of dangerous packages. I thought it best to only generate warnings for packages that are part of base-devel, seen as they don't have to be included in PKGBUILD dependencies.

As a concrete example, the UCRT64 build of mingw-w64-grep has the following issues:

  • Having mingw-w64-ucrt-x86_64-grep installed causes build() to hang indefinitely after the following output:
checking for ld used by gcc...
  • Having mingw-w64-ucrt-x86_64-sed installed causes the build to fail outright during prepare()after the following output:
autom4te-2.71: error: --trace=: no such file or directory
autoreconf-2.71: error: /usr/bin/autoconf-2.71 failed with exit status: 1
==> ERROR: A failure occurred in prepare().
    Aborting...
  • Having mingw-w64-ucrt-x86_64-file installed causes the following error message during extract():
Usage: C:\msys64\ucrt64\bin\file.exe [-bcCdEiklNnprsSvzZ0] [--apple] [--extension] [--mime-encoding]`
          [--mime-type] [-e <testname>] [-F <separator>]  [-f <namefile>]`
          [-m <magicfiles>] [-P <parameter=value>] [--exclude-quiet]`
          <file> ...`
     C:\msys64\ucrt64\bin\file.exe -C [-m <magicfiles>]`
     C:\msys64\ucrt64\bin\file.exe [--help]`

If preferable I can open an issue on Github of the above, for posterity.

Granted, mingw-w64-file seems to only cause a minor issue, and other than that the grep build succeeds. makepkg uses file to decide which decompression tool to use (see usr/share/makepkg/source/file.sh), but when mingw-w64-file fails, makepkg falls back to checking whether bsdtar can decompress it. As far as I can tell, bsdtar seems to be able to handle everything but I'm not too familiar with compression tools.

If this issue is deemed too small we can of course also remove the warning for mingw-w64-file. I am not aware of any other immediate problems with mingw-w64-file.

cyrilarnould avatar May 23 '23 17:05 cyrilarnould

I updated the PR to be a single commit (and also updated the revision)

cyrilarnould avatar May 28 '23 07:05 cyrilarnould

This is useful PR. Is there a reason it has not been merged?

oltolm avatar Jul 16 '25 11:07 oltolm