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