I love the proposal, and funny enough: It was actually one of the original
proposals of the rewritten aurweb v3 when it was moved to the git backend.

On Sat, Dec 09, 2023 at 01:18:57PM +0000, Evan Greenup wrote:
> I have some ideas to resolve or mitigate the problems above.
> 
> 1. Create a git repo on gitlab.archlinux.org named aur-meta (Or whatever names
> which maker users understand easily). This git repo keep a list (table of
> content) which point to the git repo URI of the AUR packages. 
> 
> 2. For the AUR package, it can be placed on anywhere (github.com, gitlab.com,
> gitlab.archlinux.org, gitlab.gnome.org ...), the only things needed are these
> URIs are public accessible (can be git cloned by anyone who know this URI).
> And it need to keep its PKGBUILD on the top level of git repo.
> 
> 3. The issue and affairs related to which upstream software is included and
> which PKGBUILD git repo is selected, goes to issues section of aur-meta. For
> packaging specific problems, it goes to the AUR package git repo.
> 
> 4. If a package is orphaned or too broken/bad practice, the contributor who
> has access to aur-meta can simply change the pointer to a alternative PKGBUILD
> git repo which is better in practice and liveliness.
> 
> 5. If user find there is package which need to be improved, it can firstly
> report it to PKGBUILD maintainer via the issue section of git repo. If the
> maintainer long time not response or insist to keep bad practice. The user can
> write a proposal in aur-meta to change the pointer to another alternative.
> This is what a community driven packaging method should be.
> 
> 6. The name of entry in aur-meta is the package name, not the name of PKGBUILD
> git repo. (git repo can have different name). Many upstream software author
> would create a separate git repo along with their software repo which is
> dedicated for PKGBUILD.

So generally I like the idea, you could also extend this idea with "AUR
overlays", i.e other `aur-meta` sources that could take precedence of the
"original upstream".

This would give similar capabilities to what portage from Gentoo does with it's
source packages.

In theory there could also be a new group on gitlab.archlinux.org dedicated to
AUR packages. Permissions to push towards these packages could be given out
fairly relaxed and would allow you to piggyback on the existing infrastructure
we have developed on gitlab.archlinux.org.

If you want to go even further, why not make the current official package group
an `arch-meta` repository and with a powerfull enough AUR helper you could in
theory have a source-based Arch Linux derivative easily available. I doubt this
would be an upstreamable feature into pacman, but it would be an interesting
idea to play on as well.

I don't think it would be hard to extend the current `goaurrpc` frontend to
support these features.

https://github.com/moson-mo/goaurrpc

-- 
Morten Linderud
PGP: 9C02FF419FECBE16