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-` suffix 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...

Hi AlphaLynx, Thank you for the thorough response & after reviewing the guidelines, I agree with your points about naming conventions. You're correct that my package name doesn't follow guidelines, however, the practical issue remains: `antigravity` is currently broken (incorrect binary symlink) and unmaintained (outdated, no response from maintainer). Here's a new proposition: 1. Request `antigravity` be orphaned (broken + unmaintained per AUR guidelines) 2. I orphan `google-antigravity-bin` 3. I adopt `antigravity` and fix it with: - Correct binary path - Update to 1.11.5 - Proper chrome-sandbox permissions - All improvements from my current PKGBUILD This makes sure that naming guidelines are followed, it consolidates duplicate packages and users get a working & maintained package. If `antigravity`'s maintainer (HurricanePootis) responds and fixes it first, I'm happy to orphan mine and let theirs be the standard. What do you think of this approach? Best regards, kafka On Tue, 25 Nov 2025 at 01:33, AlphaLynx <alphalynx@alphalynx.dev> wrote:

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-` suffix 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...