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#Package_naming [2] https://antigravity.google/pricing [3] https://wiki.archlinux.org/title/PKGBUILD#pkgname [4] https://lists.archlinux.org/archives/list/[email protected]/thread/IZY3AF6TT4Q64FG5INYNEJ2C5TN7YJQQ/#IZY3AF6TT4Q64FG5INYNEJ2C5TN7YJQQ [5] https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submission
OpenPGP_0x100ED08AC2F74784.asc
Description: application/pgp-keys
OpenPGP_signature.asc
Description: PGP signature
