Re: [PRQ#83804] Deletion Request for omp-bin
I'm the maintainer of omp-bin and would like to dispute both grounds for
deletion.
1. The "confusing naming vs. the unrelated omp package" claim does not hold.
- The AUR "omp" package (Open-Source Music Player, GPL3) has been orphaned
since 2019 and is a completely different program.
- The upstream project oh-my-pi ships its CLI binary as "omp" — the name
comes
from upstream, not from me. The oh-my-pi-git package already uses
provides=omp / conflicts=omp, so there is an established convention around
the
"omp" name for this project.
- omp-bin correctly declares conflicts=(oh-my-pi oh-my-pi-bin omp) and
provides=oh-my-pi, so pacman handles any collision over /usr/bin/omp
explicitly.
2. "Duplicate of oh-my-pi-bin" is differentiated by automation.
- oh-my-pi-bin was manually maintained and had no upstream check when
omp-bin was
submitted (2026-06-05). omp-bin was created specifically to provide
automatic
upstream tracking via nvchecker (+ snyk.io), deploying new releases to the
AUR
as soon as upstream ships them.
- The oh-my-pi-bin maintainer added automated tracking to their own package
only
AFTER omp-bin was published (their comment dated 2026-06-15). The approach
originated here and was later adopted by the other package.
- Two -bin packages for the same upstream with different update strategies
is not
unusual on the AUR and adds value for users who want automatic release
tracking.
3. The request does not meet the TÜO deletion criteria.
The package has a valid PKGBUILD, a working upstream, correct
conflicts/provides
declarations, and an active maintainer. It is neither redundant nor
malicious — it
offers an automated-update alternative, and I have just added oh-my-pi-bin to
conflicts to make the relationship explicit.
4. omp-bin is technically more complete than oh-my-pi-bin.
Unlike oh-my-pi-bin, omp-bin:
- Supports BOTH x86_64 and aarch64. oh-my-pi-bin only builds for x86_64,
leaving ARM users (Apple Silicon, ARM SBCs) with no binary package.
- Declares conflicts=(oh-my-pi oh-my-pi-bin omp), correctly informing pacman
of the /usr/bin/omp collision. oh-my-pi-bin only conflicts with "oh-my-pi"
and would throw a raw file-conflict error if both were installed.
- Ships optdepends (bash-completion, chromium, python) so users know about
optional features, which oh-my-pi-bin does not document at all.
- Uses provides=oh-my-pi=$pkgver for correct versioned provides, whereas
oh-my-pi-bin uses an unversioned provides=oh-my-pi.
So this is not "a worse duplicate" — it is a more complete one. Users on ARM,
and users who want correct conflict/provides metadata, benefit from keeping
it.
Request: please keep omp-bin. I'm open to coordinating with the oh-my-pi-bin
maintainer on naming/disambiguation if the TÜOs prefer, but that is a
coordination
matter, not a deletion.
