pacman-helper: tolerate removing a package absent from a database#720
Closed
dscho wants to merge 1 commit into
Closed
pacman-helper: tolerate removing a package absent from a database#720dscho wants to merge 1 commit into
dscho wants to merge 1 commit into
Conversation
The `quick_remove` action recently started to fail when asked to drop a package that no longer lives in every database it touches. Removing the obsolete `git-credential-manager-core` packages aborted as soon as the removal reached the freshly-initialized, still-empty `ucrt64` database, with `repo-remove` reporting `Package matching '...' not found.` and `quick_remove` turning that into a fatal error. This only surfaced once we taught `quick_action` to run the removal across the second and third databases (`mingw64` and `ucrt64`) in addition to the architecture database. `repo-remove` is all-or-nothing: if any requested name is absent it leaves the database untouched and exits non-zero (in /usr/bin/repo-remove a failed `remove` sets `fail=1`, after which it prints `Package database was not modified due to errors.` and exits 1). A package that only ever lived in one of the databases therefore makes the whole operation fail, even though removing a package that is not there ought to be a harmless no-op. Simply ignoring `repo-remove`'s exit code is not an option: besides papering over genuine errors, the all-or-nothing behavior would also silently skip packages that *are* present alongside an absent one. Instead, I now filter the requested names against the database's actual contents (via the existing `package_list` helper, stripping the `-<pkgver>-<pkgrel>` suffix and matching whole names so that `git-credential-manager` is not mistaken for `git-credential-manager-core`) and only hand the survivors to `repo-remove`, skipping the call entirely when nothing is left to remove. This is the run that motivated the change: https://github.com/git-for-windows/git-for-windows-automation/actions/runs/27195671090 Assisted-by: Opus 4.8 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Removing the obsolete
git-credential-manager-corepackages via the Remove Packages from the Pacman repository workflow fails as soon as it reaches the freshly-initialized, still-emptyucrt64database:repo-removereportsPackage matching '...' not found.and that aborts the entirequick_remove.The underlying
repo-removeis all-or-nothing: if any requested package name is absent from a database, it leaves the database untouched and exits non-zero. Now thatquick_actionruns the removal across themingw64anducrt64databases in addition to the architecture database, a package that only ever existed in one of them takes the whole operation down with it, even though "remove a package that isn't there" should simply be a no-op.Rather than ignore
repo-remove's exit code (which would also paper over genuine failures and, because of the all-or-nothing behavior, silently skip packages that are present alongside an absent one), this filters the requested names against each database's actual contents and only hands over the ones it actually contains, skipping the call entirely when nothing is left to remove. The match is on whole package names, so that e.g.git-credential-manageris not mistaken forgit-credential-manager-core.I verified the fix against constructed databases (package present, package absent from an empty database, a mix of present and absent, and the whole-name guard) and will follow up with a dry run of the actual workflow pointed at this branch.