msys2 dependency updating

[pjljvandelaar]

I unfortunately reported it in the wrong archive:

See commercialhaskell/stackage#6147

[mpilgrem]

I have a couple of alternative suggestions:

1. Update the existing stack-supplied MSYS2, using the stack-supplied pacman package manager (part of MSYS2), as follows:

   stack exec -- pacman -Syuu
   

   This assumes that the stack-supplied pacman is version 5.0.1.6403 or more recent. See 'III. Updating packages'. You may have to run that command more than once, until everything is reported as 'up to date' and 'there is nothing to do'.

2. Recently, the version of MSYS2 that stack downloads when the stack-supplied MSYS2 is absent has been updated to version 20220503. If you look in the stack path --programs directory and delete (or rename) the msys2-YYYYMMDD.installed file, that should trigger stack to download the updated MSYS2. However, if you start from scratch with an updated MSYS2 tool, you will lose any updates that you made to the out-of-date MSYS2 tool.

[andreasabel]

2. Recently, the version of MSYS2 that stack downloads when the stack-supplied MSYS2 is absent has been updated to version 20220503.

@mpilgrem: Was this changed without bumping the version of stack? (Speaking reproducibility of builds, stability of CI workflows...)

[mpilgrem]

@andreasabel, the short answer is Yes.

I am pretty confident that there is no connection between the version of stack and the version of MSYS2 it downloads if one is not already installed. If MSYS2 is missing, I think that all versions of stack look for the most recent MSYS2 version available to it.

As for reproducibility/stability, if you are using the stack-supplied MSYS2 to get something (like brotli, using stack exec -- pacman -S mingw-w64-x86_64-brotli) I don't think the version of MSYS2's pacman affects the version of brotli that is served up. If you depend on a specific version of brotli, you will be asking MSYS2's pacman (whatever its version) to serve up that particular version (eg 'Installing a specific version of a package or a stand-alone packages'). With MSYS2's pre-installed packages, if a specific version is important, it seems to me to be unwise to assume that that specific version will be in the MSYS2 that stack downloads (or, for that matter, in the MSYS2 that any other user of stack will have - stack only downloads MSYS2 if it is missing; if it is not missing, stack uses the version - however old - that is available to it).

The Cabal field pkgconfig-depends allows versions of C libraries to be specified. However, I have also seen things that suggest on Windows (where MSYS2 is relevant), people prefer to use extra-libraries, which does not allow versions to be specified. If that is correct, then it seems to me that a Haskell package is not specified in a 'reproducible' way in respect of any non-Haskell parts, in any event.

[andreasabel]

Thanks, @mpilgrem !

My interest is mostly in caching stack build correctly. An upstream change of MSYS2 packaging might possibly lead to problems as described in the following comment (but I am not sure):

• Windows msys2: pacman reports PGP signature errors. #5567 (comment)