-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Description
@dennisameling reported that a recent MSYS2 upgrade of OpenSSL to v3.x broke bsdtar
, which we need to build Pacman packages (including mingw-w64-git
, the core package around which Git for Windows is built).
Let's address this in the same way as we did when we had to downgrade bash
.
Previously, in such cases @vdye or I identified which version needed to be downgraded to, downloaded it from https://repo.msys2.org/, installed it in a local git-sdk-*
clone using pacman -U
, preventing it from being upgraded by editing /etc/pacman.conf
's IgnorePkg
line (and uncommenting it), committing and pushing.
This is a bit fragile and might not even work if a previous package was removed from MSYS2's Pacman repository (e.g. to save space). An alternative (that we had not tried before) would be to use only information already in the git-sdk-*
commit history to downgrade.
We could use the opportunity to automate this. What I currently have in mind is a shell script in build-extra
that takes two arguments, a package name (or even a list of package names) and a shell script snippet verifying that the downgrading fixes the underlying issue, e.g. bsdtar -h || test $? = 1
). The script would:
- identify the current package version (by expanding the
/var/lib/pacman/local/$PACKAGE_NAME-[0-9]*
wildcard pointing to a directory) - identify the
git-sdk-*
commit that added said directory - remove the files of the package (the list of files is contained in a file in that directory,
tree
ormtree
IIRC) - run the
post_remove
(orpre_upgrade
, or however it's called) scriptlet of the package if there is any (contained as shell function in theinstall
script in the directory) - reinstate the files of the previous package version (looking at the information of the parent commit)
- run the
post_upgrade
scriptlet for that version - verify that the underlying issue is fixed
- commit the files and the package directory
This could be done in a partial clone (probably even shallow, with a depth of 500 or 1000) so that it can be run efficiently in a GitHub workflow.
/cc'ing @ldennington and @jeffhostetler (because I'm mostly off of the computer until the second week of January)