Broken package for msys2 environment: mingw-w64-x86_64-hererocks; incompatible

[ItsMeForLua]

Description / Steps to reproduce the issue

When prompting MSYS2 hererocks binary to install Lua and LuaRocks, the resulting LuaRocks installation is broken for compiling and installing many packages (e.g., fennel, penlight, et cetera) due to quite significant POSIX/Native Windows pathing and tooling collisions.

Steps to reproduce:

pacman -S mingw-w64-x86_64-hererocks

Initiate hererock's local environment:
hererocks ~/lua51 -l5.1 -rlatest

Then attempt to install a package such as luarocks install fennel or luarocks install penlight.

Expected behavior

Ideally, hererocks within MSYS2 would configure the LuaRocks environment to properly bridge this gap out of the box, as that's what the tool is for (automation).

At minimum, the package setup should force LuaRocks to operate purely in Windows mode (platforms = { windows = true, unix = false }) so it uses xcopy instead of cp, and defaults to mingw32-make and MSYS2's 7zip to prevent the POSIX shell from intercepting and mangling the native Windows paths.

Actual behavior

I have identified a few causes:
Because hererocks installs the Windows build of LuaRocks, its internal path-generation hardcodes native Windows backslashes (C:\tools...). However, by default, it relies on POSIX utilities (/bin/sh, cp, unzip) provided by the MSYS2 shell.

The consequence of this is distinct in three particular points:
MSYS2 POSIX unzip fails when passed the Windows paths generated by LuaRocks.

POSIX /bin/sh strips the backslashes out of the execution paths passed to it by LuaRocks' make step, resulting in a mangled path error "looking for lua51binlua.exe".

When a package requires copying directories (like penlight), LuaRocks invokes the POSIX cp tool with a wildcard (cp -p -r lua/* C:...). The MSYS2 shell triggers cygwin glob expansion on the wildcard, interprets the backslashes in the destination path as escape characters, and mangles the path, which naturally leads to a failed installation.

Expanding on the expected behavior section:
Even after doing this; even if you fix the paths, windows paths are still appended onto the corrected paths in later steps of installation of a library. I personally found a hacky patch for this, where you just see what executable it's looking for, and you name a symlink to the actual executable, the mangled path name. (naturally the environment strips out the back slashes; giving you a merged path appended to the correct path, for the executable in question (i.e., lua51binlua.exe.

---

For full debug logs and the chronological debug session of this issue, please see the upstream issue here.

FYR:
https://packages.msys2.org/base/mingw-w64-hererocks
luarocks/hererocks#55
https://github.com/luarocks/hererocks

Verification

• I have verified that my MSYS2 is up-to-date before submitting the report (see https://www.msys2.org/docs/updating/)

Windows Version

MINGW64_NT-10.0-26200---Windows_NT

Are you willing to submit a PR?

To some degree, yes.

[ItsMeForLua]

Though, later tonight or tomorrow there will be an additional comment furthering the debug process. As there are some very specific bugs still prevalent.

Phantom files, and missing wrappers especially. Additionally, in some regards, yes, fennel was successfully compiled, however, one could also say it's falsely giving a success message, because technically it did not successfully complete post-install wrappers, copying, et cetera.

Everything really boils down to the executable being only windows native.

Then, along with accounting for what the executable expects, you also have to account for the abstraction leaks inevitably caused by msys2's environment clashing with a windows executable.