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

Hello Evan, So basically this is about separating the package metadata and the location of the build recipes. Allowing to use arbitrary git repos to store the PKGBUILD's (so folks can file issues/MR's against those rather than having to contact the maintainer via AUR-comments/email) if I understand correctly. On 12/9/23 14:18, Evan Greenup wrote:

1. Difficult to feedback and difficult to contribute (to already existed package). If have any ideas or report, user need to send email to maintainer via email personally. This is not convenient for both maintainers and users.

You could also just leave a comment on the package page... (well ok, you'd need an AUR account). With the above concept you'd need an account for all the different platforms where the PKGBUILD is hosted to file your issues/MR's, etc.

2. Lack of Peer review, audience supervise. Some packages even if updated frequently by its maintainer, but it doesn't following good practice and not built from source (Not Java, native program), It retrieve from Debian or Ubuntu or Fedora packages, and extract or repackage it in Arch Linux package. And some packages may failed to build, or some of its dependencies are forgotten added by maintainer.

I'd hope there are tons of reviewers (the users of those packages) ;). If something doesn't build you'll see some comments pretty quickly.

3. The entry with a specific name in AUR is always occupied by the Maintainer who firstly register the package. If there is another maintainer who has better practice than the previous one, This maintainer has to rename his/her package as `xxx-bin` or some sophisticated name else. This is unfair. It lack of refreshing mechanism.

There is the concept of co-maintainers. Maintenance for a package can be handled by multiple people at the same time. If a package is not properly maintained, there are ways to address that (orphan request). You don't simply use a "-bin" extension or some other name to be able to provide "your nicer version" of an already existing package. I don't see how that split meta/PKGBUILD concept would improve that situation though.

4. upstream software author is difficult to directly contribute to the AUR packaging contribution. For a great number of upstream software author, they are willing to participate in downstream redistribution process. Especially for those young software. But the current AUR workflow block their way to contribute on downstream stuff.

I'd guess most of software developers would be happy that someone else is handling that for them. Anyways, why are they blocked to maintain their own software as an AUR package themselves?

5. Currently,to evaluate whether a AUR package is eligible to move in Arch Linux official packages (extra repo), It only depend on votes and popularity and whether there is a maintainer willing to pick it up. However, those factors is too lack of details. To evaluate the robustness of the eco-position of a package, It should evaulate the discussion, issue report, contribution, and ... And it should be evaluated case by case.

Votes and popularity are just indications for how popular a package is. They maybe help to bring things onto "the radar" of package maintainers, however, the decision of moving a package is entirely up to them. I don't see how "issue reports in a foreign repository" help them deciding on whether to move a package to the repos or not.

The design above, is just for demonstrate ideas, improvements can be made further.

I guess my major (technical) concern for this split-up would be: How to make sure the metadata in `aur-meta` is in sync with the .SRCINFO/PKGBUILD in the foreign repo? Let's say a maintainer wants to bump the version, they would need to a. Change and push the PKGBUILD to their repo and b. somehow update the metadata (or trigger an update) in `aur-meta` at the same time. (I don't think it would be feasible to constantly/periodically crawl and parse data from 110k upstream repositories to update the metadata in `aur-meta`). I'd suggest to file an issue/feature request at the aurweb project over at gitlab for further discussion: https://gitlab.archlinux.org/archlinux/aurweb regards, MO