Oops I messed up the quoting, for transparency here it is correctly: On 11/22/25 6:26 AM, Joseph Brandon Kigen wrote:
I disagree with this merge request. Here's the current situation:
There are currently 6 AUR packages for Google Antigravity: - antigravity-bin (13 votes, most popular) - antigravity-bin-hardened (2 votes, specialized variant) - google-antigravity-bin (2 votes, *mine*) - antigravity-preview (0 votes) - antigravity-binary (0 votes) - antigravity (0 votes, *requester's package*)
The `-bin` suffix is standard AUR practice for binary packages. The requester's package name "antigravity" without suffix is actually the non-standard one.
According to the guidelines [1], the `-bin` suffix should be used when source code of the software is available, or if it's likely that source code will exist in the future. Google seeks a profit from Antigravity [2] so almost certainly we will never have source code for it. Therefore, there shouldn't be a `-bin` suffix.
The requester's package (antigravity) has critical issues: - *Outdated* (v1.11.2 vs current v1.11.5) - *Broken binary symlink* (points to capital-A "Antigravity" which doesn't exist) - *Not* maintained (last updated Nov 18, now Nov 22) - Zero votes, indicating no user adoption.
By the way, I am not the maintainer of `antigravity`. If they were to orphan it, I'd happily pick it up and fix it.
google-antigravity-bin is: - Correctly structured and functional - Following proper naming conventions
The `google-` prefix does not follow naming conventions. Typically, package names keep the name of the software [3]. There's no need for a suffix of the name of the creator, "Google" can instead just be in the description.
The most popular package (antigravity-bin with 13 votes) also uses the `-bin` suffix, confirming this is the accepted convention.
The convention is `-bin` when sources exist, no `-bin` when there are no sources. See Package Maintainer response on PRQ#77614 [4].
If consolidation is desired, it should be around the most popular and correctly- named packages (antigravity-bin or google-antigravity-bin), not the broken, unmaintained "antigravity" package with zero adoption. The requester should orphan their package, not request others merge into it. The request should be rejected.
No, according to the guidelines [5], if a package is broken, changes should be submitted to the Maintainer.
Given the fragmentation (6 packages doing more or less the same thing), I propose: 1. Keep the two legitimate -bin packages: - antigravity-bin (most popular, 13 votes) - google-antigravity-bin (my package, proper Google branding)
2. Keep specialized variants: - antigravity-bin-hardened (serves specific security use case)
3. Orphan/remove broken/duplicate packages: - antigravity (broken, unmaintained) - antigravity-preview (outdated, unclear purpose[Suggests preview but fetches from the same source as per its PKGBUILD]) - antigravity-binary (duplicate of -bin packages)
I'm willing to orphan my package in favor of antigravity-bin IF the community prefers consolidation around that name. However, merging into a broken package makes no sense.
Since it is identical software, there should only be 1 package, `antigravity`. It doesn't matter if that package is currently broken, changes should be submitted to that maintainer, or it should be orphaned, and duplicate packages should not be created. Best Regards, AlphaLynx [1] https://wiki.archlinux.org/title/Nonfree_applications_package_guidelines#Pac... [2] https://antigravity.google/pricing [3] https://wiki.archlinux.org/title/PKGBUILD#pkgname [4] https://lists.archlinux.org/archives/list/aur-requests@lists.archlinux.org/t... [5] https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submissi...