Fix bootstrapping MSYS2 pacman (#11499)#12080
Fix bootstrapping MSYS2 pacman (#11499)#12080BillyONeal merged 3 commits intomicrosoft:masterfrom endrift:endrift-pacman
Conversation
MSYS2 pacman recently transitioned to using .zstd packages from .xz packages, but we bootstrap from a pacman that doesn't support those. We need to add some additional bootstrap steps before pacman works.
|
CLA signed. And that sounds like a good start. I thought about adding a helper routine for invoking pacman instead of copying a bunch of stuff repeatedly. Also, errors aren't checked for yet, so the script could be a lot more robust than it is right now. |
|
@endrift Thanks! |
|
@emptyVoid Could you review this PR? Thanks. |
|
VTK failures would be fixed via #12067 |
|
Needs merge this PR before merge #12067. |
emptyVoid
left a comment
There was a problem hiding this comment.
#11499 should had been fixed by #11443.
The dash part looks like a good workaround for the current MSYS2 disability (which is explained here msys2/MSYS2-packages#2022).
| # we need to update pacman before anything else due to pacman transitioning | ||
| # to using zstd packages, and our pacman is too old to support those | ||
| _execute_process( | ||
| COMMAND ${PATH_TO_ROOT}/usr/bin/bash.exe --noprofile --norc -c "PATH=/usr/bin;pacman -Sy pacman --noconfirm" | ||
| WORKING_DIRECTORY ${TOOLPATH} | ||
| ) |
There was a problem hiding this comment.
This part is not needed (see msys2/MSYS2-packages#1962 (comment)).
The same approach was first implemented in #11443 (merged the next day after #11499), and it stopped working the moment upstream changed compression scheme for some of pacman dependency packages to zstd, then we resorted to a workaround you can now see in #11443. The workaround was removed in #11810 as obsolete since upstream reverted core packages to xz.
There was a problem hiding this comment.
They're zstd again, at least when I tried earlier today.
There was a problem hiding this comment.
If you are referring to the errors seen in msys-pacman-*-err.log, those are for non-core packages.
At the moment vcpkg_acquire_msys silently ignores any errors in Acquiring MSYS2... region, as it does not use RESULT_VARIABLE of _execute_process function. Thus the core system upgrade fails, and pacman stays at some old version which is unable to install zstd packages.
There was a problem hiding this comment.
If we don't need those packages why not just update pacman instead of all the packages?
There was a problem hiding this comment.
We do not update all the packages, we only do the core system upgrade so that any subsequent package installs would succeed. Some of the packages vcpkg ports require depend on the core packages, and the core packages could not be upgraded in the same shell with non-core installs.
There was a problem hiding this comment.
There's a pacman -Syu in there that I didn't add, so yes you do update all the packages. I can try removing it and seeing if any additional tests fail, but I'm not sure I should touch that.
There was a problem hiding this comment.
Yes, I'm referring to pacman -Syu too -- it actually updates the package database and makes a core system upgrade only (see MSYS2 Installation step #5). To upgrade all the packages an additional pacman -Su command is necessary.
There was a problem hiding this comment.
Oh, yes, because of how MSYS2 works. I forgot about that. I'll try it without my first pacman -Sy pacman.
|
Thanks so much for your help! |
MSYS2 pacman recently transitioned to using .zstd packages from .xz packages, but we bootstrap from a pacman that doesn't support those. We need to add some additional bootstrap steps before pacman works. Note that this conflicts with #12044, so one of us will have to edit their PR to match the other.
Describe the pull request
What does your PR fix? Fixes [poco:x64-mingw] build failure #11499
Which triplets are supported/not supported? Have you updated the CI baseline? These changes shouldn't affect different triplets since it uses an internal msys2 tree.
Does your PR follow the maintainer guide? To the best of my knowledge yes.