Follow-up after checking the current Cursor update endpoints: cursor-early-access-bin is intended to track Cursor's prerelease / Early Access update endpoint. I checked the current endpoint state, and at the moment prerelease resolves to the same Linux artifact as stable:
prerelease: 3.5.38, commit 009bb5a3600dd98fe1c1f25798f767f686e14759 stable: 3.5.38, commit 009bb5a3600dd98fe1c1f25798f767f686e14759 So I understand the duplicate concern in the package's current state. My question about cursor-nightly-bin was about the general standard being applied to release-channel packages. cursor-nightly-bin currently does resolve to a distinct dev artifact/version, while cursor-early-access-bin currently does not. That makes the present case clearer. That said, I would prefer not to treat this as a categorical issue where Cursor's Early Access channel can never have a separate package. The package tracks a real upstream prerelease endpoint, and that endpoint may diverge from stable again when Cursor publishes another Early Access build. I am happy to update my automation so it monitors the prerelease endpoint but does not publish a new cursor-early-access-bin release when prerelease resolves to the same artifact as stable. If the prerelease endpoint diverges again, the package would track that distinct artifact. If it continues to resolve to stable and there is no distinct Linux Early Access artifact to package, I will request deletion/merge myself. Would it be reasonable to defer this request for a few days while I verify whether the prerelease endpoint diverges again? On Wed, May 27, 2026 at 8:46 PM Augie Luebbers <[email protected]> wrote: > Could the requester or a Package Maintainer clarify the duplicate standard > being applied here? > > The deletion request says “Changing release channel does not avoid it,” > but cursor-nightly-bin also exists specifically because it tracks a > different release channel from cursor-bin. If nightly is considered > sufficiently distinct from stable, I do not understand why Cursor’s Early > Access/Beta channel would be categorically treated as a duplicate. > > I agree that a package should be deleted if it downloads the exact same > upstream artifact as an existing maintained package. But if the relevant > distinction is upstream release channel, version stream, source URL, > checksum, or update cadence, then Early Access seems meaningfully different > from both stable and nightly. > > I am happy to update pkgdesc, comments, and provides/conflicts to make > this clearer. But before deletion, I would appreciate clarification on why > cursor-nightly-bin is acceptable while cursor-early-access-bin is not, > assuming this package tracks a distinct upstream Early Access > artifact/channel. > > On Wed, May 27, 2026 at 8:12 PM <[email protected]> wrote: > >> oech3 [1] filed a deletion request for cursor-early-access-bin [2]: >> >> Dupe of cursor-nightly-bin or cursor-bin . Changing release channel >> does not avoid it. >> >> [1] https://aur.archlinux.org/account/oech3/ >> [2] https://aur.archlinux.org/pkgbase/cursor-early-access-bin/ > >
