Skip to content

pacman-helper: tolerate removing a package absent from a database#721

Merged
dscho merged 1 commit into
mainfrom
pacman-helper-remove-missing
Jun 20, 2026
Merged

pacman-helper: tolerate removing a package absent from a database#721
dscho merged 1 commit into
mainfrom
pacman-helper-remove-missing

Conversation

@dscho

@dscho dscho commented Jun 20, 2026

Copy link
Copy Markdown
Member

Removing the obsolete git-credential-manager-core packages via the Remove Packages from the Pacman repository workflow fails as soon as it reaches the freshly-initialized, still-empty ucrt64 database: repo-remove is all-or-nothing and exits non-zero when a requested package name is absent, which quick_remove then turns into a fatal error. Now that the removal runs across the mingw64 and ucrt64 databases 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 that git-credential-manager is not mistaken for git-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

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>
@dscho dscho marked this pull request as ready for review June 20, 2026 16:28
@dscho dscho merged commit 015621c into main Jun 20, 2026
11 checks passed
@dscho dscho deleted the pacman-helper-remove-missing branch June 20, 2026 16:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant