git-extra(i686): remove libunistring workaround

[jeremyd2019]

After git-for-windows/MSYS2-packages#219 the extra file is no longer needed.

[jeremyd2019]

Or I could just make a PR against git-sdk-32 removing the file 😁

[jeremyd2019]

hmm, was thinking it'd be a good idea to make sure no package owns the file before removing it, but now I'm concerned about calling pacman from an install script - the pacman calling the script is probably still holding the db.lck...

[dscho]

/deploy git-extra

The i686/x86_64 and the arm64 workflow runs were started.

[dscho]

/deploy git-extra

Dangit. I should have rebased this PR after merging #595... Since I did not, the changes were not in effect and the changes were not reflected in https://github.com/git-for-windows/pacman-repo... Will synchronize that now, manually.

[jeremyd2019]

cool. I just confirmed that this worked. Guess it is OK to call pacman from the install script (at least -Q).

[dscho]

Guess it is OK to call pacman from the install script (at least -Q).

Well, in line with the insane tradition originally pursued even by Git, namely to rely on Unix shell scripts in production code (including the outstanding and excellent error checking, type safety and locking capabilities of that language </s>) it is no surprise to me that Pacman might still perform some operations improperly not under a lock ;-)

[dscho]

/deploy git-extra

Dangit. I should have rebased this PR after merging #595... Since I did not, the changes were not in effect and the changes were not reflected in https://github.com/git-for-windows/pacman-repo... Will synchronize that now, manually.

Here it is:

• The GitHub release for the i686/x86_64 deployment.
• The x86_64 deployment commit.
• The i686 deployment commit.
• The GitHub Release for the aarch64 deployment.
• The aarch64 deployment commit.

And with this, I really call this PR done.

[jeremyd2019]

Guess it is OK to call pacman from the install script (at least -Q).

Well, in line with the insane tradition originally pursued even by Git, namely to rely on Unix shell scripts in production code (including the outstanding and excellent error checking, type safety and locking capabilities of that language ) it is no surprise to me that Pacman might still perform some operations improperly not under a lock ;-)

Actually, maybe it did fail... I send stderr and stdout to /dev/null, and the if check wants it to fail, so it very well could have failed due to a locked db rather than the file not being owned

[dscho]

But it removed the libunistring-2.dll?

[jeremyd2019]

yes, because the arch was i686, the msys-unistring-2.dll existed, the pacman call failed (either due to the msys-unistring-2.dll not being owned by any package, or due to the database being locked by the pacman currently installing git-extra), and the grep failed (not matching msys-unistring-2 in msys-gnutls-30.dll.

It doesn't really matter at this point, it did what it was supposed to do, and won't do it again because the file's gone (and presumably that chunk will be removed the next time there's a git-extra update).

[dscho]

It doesn't really matter at this point, it did what it was supposed to do, and won't do it again because the file's gone (and presumably that chunk will be removed the next time there's a git-extra update).

Right. I'd leave it in for a few moments, though, because there are still a number of people who ignore my warnings that installing Git for Windows in MSYS2 proper is not supported and they should do that only if they can fix it themselves if things go wrong (which many of them actually cannot, and then open tickets in git-for-windows/git, to my great annoyance).