I loved it.
Which steps do you folks think are necessary to make aur-meta dream come
true?
How to help with aurweb v3 development tasks?
Best!
On December 9, 2023, Morten Linderud
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.
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
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-
On Sat, Dec 09, 2023 at 01:18:57PM +0000, Evan Greenup wrote: this URI). 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