LWP::Protocol broken by missing dependency
djgraff209 opened this issue · 12 comments
Commit 4bbbc6b introduced a newer version of LWP::Protocol
What is the Pacman package's name and version?
that depends on Try::Tiny
What is the Pacman package name & version?
Is this a new depedency that was incorrectly not specified in the Pacman package containing LWP::Protocol? If so, please modify the PKGBUILD in the corresponding subdirectory of https://github.com/Alexpux/MSYS2-packages.
I have identified the dependency in MSYS2-packages as perl-Try-Tiny.
I believe that this was not identified in the LWP package (perl-libwww).
How should this be addressed?
- File issue against Alexpux/MSYS2-packages
- Submit PR for Alexpux/MSYS2-packages/perl-libwww adding the dependency
I can do that a little bit later today if that is the case.
And by "a little bit later today" of course I meant like right friggin now :-)
PR available msys2/MSYS2-packages#1233
I have updated the PR on Alexpux/MSYS2-packages.
I will go through versions of git-for-windows that are impacted on this and identify which versions (and later) would need to be either patched/rev'd/re-released.
And by "a little bit later today" of course I meant like right friggin now :-)
:-) I also updated the Git for Windows SDKs.
I will go through versions of git-for-windows that are impacted on this and identify which versions (and later) would need to be either patched/rev'd/re-released.
Wait, this affects end-user Git for Windows? What parts of Git require Try::Tiny?
The bundled version of perl included the MSYS2 packages. At my job we were integrating a message hook that couldn't be expressed properly in shell due to escaping issues, I implemented the hook in perl and used the LWP library under 2.14.2 of g-f-w. When my ops guys deployed they used the 2.16.2 version which choked because of this missing dep.
Issue msys2/MSYS2-packages#1235 (merge of msys2/MSYS2-packages#1233) has been completed. This should resolve the dependency issue.
At my job we were integrating a message hook that couldn't be expressed properly in shell due to escaping issues, I implemented the hook in perl and used the LWP library under 2.14.2 of g-f-w.
Okay. That is unfortunate in your case, of course, but I would not deem this a Git bug that is fixed. So I am very reluctant to set aside all the time needed for maintenance releases, as you suggested earlier. Time's at a premium.
Issue msys2/MSYS2-packages#1235 (merge of msys2/MSYS2-packages#1233) has been completed. This should resolve the dependency issue.
Yes, and that will be fixing the end-user facing Git for Windows installer/portable Git, in the next version.
In all honesty the back trace was only to identify which versions would have been impacted. I would not expect a set of regression/patch releases to address this. Latest version would suffice
Phew! Good, I thought you wanted me to release new MinGit versions (which is the only Git for Windows flavor for which I maintain older release trains)... That would have been a hassle, and I am glad that I can avoid it.
Latest version would suffice
I guess you cannot convince your admin to go to a snapshot release? These snapshot releases are built and published every time Git for Windows' master advances, and as I try very hard to keep master in a ready-to-release state in Git for Windows at all times, I would consider any snapshot release that is not immediately (read: within at most hours) followed by a fixup! commit as pretty solid...
Guessing what your next question would be: As to when the next Git for Windows version will be released, there is nothing on my radar yet. No crucial Git for Windows bug fix that would merit a v2.17.0(2), I am unaware of any indication for a v2.17.1 (typically this would be hinted at in the What's cooking mail by Git's maintainer), and the official time line for v2.18.0 says nothing about the next major release yet (in the past, a 12-week cycle was the rule, so I would expect v2.18.0 to be released on or about June 25th). Whenever Git releases a new version, I try to release a new Git for Windows version within 24h.
There is literally NO rush on this - At the time this occurred (last Wednesday) I was assisting the DevOPS group in fixing up the post-receive hook notification that had been improperly implemented. I implemented on Apache24 (win x64) / GitForWindows 2.14.2 (64-bit). There was some carping about the fact that we were stuck on 1.9.5 because that's what we had to use with Apache24 (long and short of that was I nearly called a few people out on not "owning" the problem to completion).
While staging the binaries etc to install on the target sever, one of the resources asked if they could use the latest version. With the general stability of the releases over time (kudos on that!) I said to go ahead. When things puked because of the LWP dep that was missing we were scrambling as the system (while not production level) was going to impact a number of teams if not restored to working order.
Anyway, the version we're on now is fine, the upcoming versions will be tracked.
Thanks again for running this down and including it.
I'll check the new release versions when they pop up and at least look at the portable one for the dep.
Okay, cool. Thanks for the background information, it was a very interesting read!
I'll call this ticket addressed, then ;-)