aurupdater

tea

2026-11-05: adoption attempted, then abandoned after discovering a real three-way name collision

Flagged as dropped from extra (gitlab packaging history for the official tea package – “A command line tool to interact with Gitea servers”, Go-based – last touched 2026-11-04). Initial research (AUR RPC resultcount: 0 for both tea and gitea-tea) wrongly concluded both names were free. Both RPC results were misleading – confirmed repeatedly via git ls-remote/git fetch against the real AUR SSH host, which is ground truth regardless of what the RPC API reports.

What’s actually on AUR right now, independent of this official Gitea-CLI package:

  1. tea – a real, actively-maintained, completely unrelated package: a Qt6 text editor (tea.ourproject.org, maintainer Fabio ‘Lolix’ Loli, pkgver=60.4.0). Also installs /usr/bin/tea – genuine binary-path collision, confirmed via that project’s own CMakeLists.txt (add_executable(tea ...)), not just a name clash. This is the same pkgname slot that Arch’s own gitlab packaging history for the official tea (Gitea CLI) shows being vacated via a tea: move to AUR commit, decades of unrelated SVN-era history before that (hunspell/libpng rebuilds – a different old GTK editor, also called “Tea”) – the AUR tea today is yet a third identity at this name (a Qt6 port of that same old editor lineage, new maintainer).
  2. gitea-tea – a real, legitimately-related but stale AUR package: the actual original packaging of this same Gitea CLI tool, by John K. Luebs (# Maintainer: John K. Luebs), stuck at pkgver=0.7.0 with a plain make-based build (no proper ldflags, no completions, no man page). This explains the official PKGBUILD’s own replaces=(gitea-tea) line – it exists to handle upgrades from this stale AUR package once the tool graduated into official extra under the plain name tea, not as a hint that gitea-tea was a safe fallback name.

So: adopting under tea would silently overwrite/collide with unrelated software at the filesystem level; adopting under gitea-tea would mean taking over a real AUR package that may or may not still have an active maintainer (not checked), which needs AUR’s own orphan/merge process, not just a force-push.

Full sequence this session (for context, not to be repeated): cloned Arch’s gitlab packaging history via pkgctl, found the history needed cutting (only ~26 of ~103 inherited commits were genuinely about this package – see the git-log-boundary technique: git log --oneline --reverse + git log -S "<unique pkgdesc phrase>" --reverse to find the real start, git replace --graft <boundary-commit> + git filter-repo --force to cut cleanly), tried pushing as tea (rejected, non-fast-forward, exposed the editor collision), renamed to gitea-tea and added conflicts=(tea) once the binary-path collision was confirmed, built and published both attempts to archlinuxaba under pkgrel ½ – then discovered the gitea-tea collision too once the user checked out the real AUR repo directly. User decision: drop the whole adoption, remove everything.

Cleanup done: local arch/maintained/gitea-tea directory removed (never a registered git submodule, nothing to git rm/deinit), build staging dir /data/INSTALL/gitea-tea removed, and the erroneously published tea/tea-debug/gitea-tea/gitea-tea-debug package files removed from the live archlinuxaba repo db (repo_remove_remote, the same primitive repo_publish.sh uses internally) with their files moved to the archive dir rather than deleted outright, per the archive’s append-only convention.

Lesson for future adoptions generally: a resultcount: 0 AUR RPC answer is not reliable proof a name is free, especially for a name this project’s own drop-scan just flagged (suggesting recent AUR-side churn). Confirm via git ls-remote ssh://aur@aur.archlinux.org/<name> (or an actual git fetch) before concluding a name is actually available – do this for every candidate name under consideration, not just the first one tried.