mingw-w64-innoextract: pull in Inno Setup 6.4.2..6.7.1 support#29441
Conversation
|
This approach makes it hard to go back to upstream in case the revision count on the fork is larger than the resulting upstream one. We'd need to bump epoch then. Do you mind if I just apply https://github.com/msys2/MINGW-packages/pull/29441.patch on the original git instead? |
|
Why don't we just wait for the upstream pull request (dscharrer/innoextract#210) to get merged? |
@lazka of course! I should have thought of that myself. I'll make the updates in a minute.
@striezel I would love for that Pull Request to be merged. However, their contribution charts don't get my hopes up:
Also, since there are only commits of a single committer, I now have doubts that my upstream PR will go anywhere:
|
Recent Git for Windows installers are built with Inno Setup 6.7.x, and the currently-packaged innoextract bails out on the SetupID magic for any Inno Setup version newer than 6.4.1. That is a concrete regression for users who rely on innoextract to inspect or unpack Git for Windows installers, and presumably other installers built with current Inno Setup releases. To address that, dscharrer/innoextract#210 adds on-disk format support for Inno Setup 6.4.2, 6.4.3, 6.5.0 through 6.5.4, 6.6.0, 6.6.1, 6.7.0, and 6.7.1, in 11 commits on top of the upstream dscharrer/innoextract master tip. That PR is currently a draft upstream. Rather than pointing _commit at a personal fork carrying those commits, keep this package close to upstream: _commit stays pinned to the upstream tip, the 11 commits are exported via git format-patch and applied in prepare() with a patch -Np1 loop, and only pkgrel is bumped. Once dscharrer/innoextract#210 is merged, the patches can be dropped and _commit re-pinned to a commit that already contains them. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
419e248 to
909fd4a
Compare
Done! I ended up doing not a single big patch, but simply exporting the Git commits as patches, for ease of verification and iterating. |


Recent Git for Windows installers are built with Inno Setup 6.7.x, and the currently-packaged
innoextractbails out on theSetupIDmagic for any Inno Setup version newer than 6.4.1. That is a concrete regression for users who rely oninnoextractto inspect or unpack Git for Windows installers (and presumably other installers built with current Inno Setup releases).To address that, dscharrer/innoextract#210 adds on-disk format support for Inno Setup 6.4.2, 6.4.3, 6.5.0 through 6.5.4, 6.6.0, 6.6.1, 6.7.0, and 6.7.1 (11 commits on top of
dscharrer/innoextractmaster). That PR is currently a draft upstream.This PR bumps
mingw-w64-innoextractto that series so the new format support is available to MSYS2 users now, rather than after the upstream PR has gone through review. Concretely,_commitis moved from6e9e34ed0876014fdb46e684103ef8c3605e382e(upstream master tip at the time of writing) to0254c3f11e34701000ad763be7753623f81152bf(the tip of my fork''s branch backing the upstream PR); thesource=URL is temporarily switched fromgit+https://github.com/dscharrer/innoextracttogit+https://github.com/dscho/innoextract, with theinnoextract::rename prefix so the on-disk source directory name is unchanged;pkgveris updated from1.9.r82.6e9e34eto1.9.r93.0254c3f, matching what the existingpkgver()function computes for the new commit (the 11 added commits advance the rev count from 82 to 93); andsha256sumsis regenerated viaupdpkgsums. A four-line comment abovesource=marks the personal-fork URL as temporary and points at dscharrer/innoextract#210, so it is obvious what needs to happen once that PR is merged: revert the URL todscharrer/innoextractand re-pin_committo the resulting upstream commit.There are essentially two paths and the choice is yours: merge now, giving users 6.4.2..6.7.1 support immediately at the cost of temporarily sourcing from a personal fork; or keep this open as a tracker and bump to the resulting upstream commit once dscharrer/innoextract#210 is merged. I am happy to revise this PR to drop the
dscho:URL and re-pin to adscharrer:commit as soon as that PR lands, in either case.One thing I deliberately did not touch: the
validpgpkeysline is left as-is, even though my commits are not signed with Daniel Scharrer''s key. That key was used for tag verification, and thisPKGBUILDpins by commit hash rather than verifying a signed tag, so the line is metadata-only in this context. Removing it is orthogonal to this update and probably a decision worth making consistently across all packages that pin by commit, rather than as a drive-by here.