Hi,
On 09-12-2023 14:18, Evan Greenup wrote:
Hello,
AUR is a unique feature for Arch Linux (include derived distros). It significantly expand the Arch ecosystem.
However, for the current infrastructure and workflow for AUR, there are some drawbacks.
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.
There is indeed a lack of Pull Requests, which would make it vastly
easier to contribute. It would be interesting if someone can figure out
how easy it is to implement that into the AUR.
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.
That honestly, will always happen. There are simply too many packages in
the AUR to make them all follw them. But this is more of point 1, no
easy way to provide patches except of comments.
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.
This is not a technical problem, a community one. We have co-maintainers
so others can help out maintaining. I don't think making it easier to
override a package with a "better PKGBUILD" is a great idea, it doesn't
solve point 2. it just hides the problem.
Or if this is an problem with co maintainers not being able to take over
the package that is a bug in AURWeb.
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.
This is another case of lack to of being able to make a PR.
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.
Not sure what I think of this, a package maintainers picks something up
if they use it and see value in having it in the repos.
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.
I understand the demand for having a proper issue tracker and proper
merge requests. But splitting the information in two places is a no no
for me and makes the whole situation rather confusing. You would have
two sources of truth for the AUR package from my understanding, one in
an external Git host and one on aur.archlinux.org.
A few problem I see is:
* This text list needs to be synced from the AUR
* The maintainer list on the AUR would become useless which would I find
rather sad
* Taking over a package becomes a new out of the AUR requests procedure
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.
That I kinda doubt, but I see value in the idea. For work we keep the
PKGBUILD in the same repo as the software and we consider opening a PR
automatically when a release happens to the Arch repo package.
I hope you don't take this too negative, I understand the problem that
contributing to the AUR is hard if you are not a Maintainer or
Co-Maintainer and welcome to file issues except via comments / mail.
P.S. please send such proposals to aur-general@xxxxxxxxxxxxxxxxxxx and
aur-dev@xxxxxxxxxxxxxxxxxxx in the future.
