pacman-helper: tolerate removing a package absent from a database#721
Merged
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
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-removeis all-or-nothing and exits non-zero when a requested package name is absent, whichquick_removethen turns into a fatal error. Now that the removal runs across themingw64anducrt64databases in addition to the architecture database, a package that only ever lived in one of them takes the whole operation down with it, even though removing a package that is not there should simply be a no-op.Rather than ignore
repo-remove's exit code (which would also mask genuine failures and, given 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 contains, skipping the call entirely when nothing is left. The match is on whole package names, so thatgit-credential-manageris not mistaken forgit-credential-manager-core.This branch was used in a workflow run to successfully remove
git-credential-manager-core: https://github.com/git-for-windows/pacman-repo/releases/tag/2026-06-20T16-25-40.977931900Z