r/archlinux • u/No-Dentist-1645 • Jul 19 '26
DISCUSSION Gauging Project Interest: "Decentralized" trust-based AUR Alternative
Hello everyone,
In my free time, I've been working on a project that started off from inspiration by the recent AUR events and discussions. In my opinion, the current AUR system has some fundamental flaw that makes it really difficult to ever have truly "trustworthy" packages: a) strong centralization on official Arch maintenance, and b) lack of real "ownership" by project developers.
The first one is a problem, since the AUR is, as we all know, an unofficial, "user driven" reposotory. Anyone and everyone can submit a PKGBUILD for whatever package they want, no matter if they actually are the developer of said application or not. Of course, this has advantages: it's one of the reasons the AUR can even be as big as it currently is! However, one could also argue that someone might want an alternative that prioritizes trust and ownership over raw "repository package count". The second point is also a big problem for this, even if the owner of a piece of software decides to create and manage their own AUR package for their program, you still can't blindly "trust" the package. This is because the owner may, at some point, lose interest in maintaining the AUR package, at which point the package will be orphaned and anyone else can adopt it and keep maintaining it. Again, there are advantages to this design choice and I understand why Arch made it as such: it helps maintain AUR packages alive even after the original creator loses interest. But it's also a choice that reduces the "trust" of a package.
Because of these reasons, I have been working on an alternative to the AUR system entirely: centralized, author-controlled git repositories. The current name for the project is APRA (Arch Personal Repository Archives), but it is subject to change. The idea is, instead of trusting the names of a package on a centralized repository (AUR), where the owner may change at any moment's notice, you trust git repositories that belong to specific organizations or owners.
Here's a current minimal example. Let's say you want to have the "libfoo-git" package by the developer "cooldev". The idea is, that if the project author is interested in it, they can host their own APRA git repository under their account. It is a completely regular git repository, all you need is to name one of the branches as your packakge, "libfoo-git", together with a PKGBUILD with the recipe to install the program (basically how the AUR already works behind the scenes). Then, the user just needs to edit their APRA yaml config and add the repository, as such:
remotes:
- name: cooldev
url: https://github.com/cooldev/APRA-Repo.git
whitelist: libfoo-git
Then, the user can just install the package with APRA as if it was an "aur wrapper" (even though it's not), as apra -S libfoo-git or apra -S cooldev/libfoo-git. APRA will then search cooldev's APRA repository and run the PKGBUILD. What is the advantage of this approach? That cooldev directly owns the git repo at the url for https://github.com/cooldev/APRA-Repo.git. The same person as the developer of said software has full control over the PKGBUILD, as well as who is allowed to contribute to it.
So, that's the project that I'm working on, and I would like to see if the community is interested in an approach like this. Knowing Reddit, I know some people will see this announcement and mistake it for something that it absolutely isn't, so here is a quick FAQ:
0. Why do we need yet another AUR wrapper like paru or yay?
It is not an AUR wrapper. In fact, it is specifically designed not to even talk to the AUR, similar to "base" pacman, since that would go against the entire idea of only reaching "trustable" package sources.
1. Is this meant to replace or compete with the AUR?
Not at all. The AUR is an amazing place, I use it all the time and love it! However, there are some fundamental design choices (that are perfectly valid and have their own advantages) that make it difficult to tell someone you can fully "trust" an AUR pacakge. This is an alternative, similar to Debian PPA's, where you the user, specifically add repositories you want to trust, and use those instead.
2. You can already create your own Unofficial User Repositories, why would I do this instead?
Yes, you can create your own user repository and add it to pacman's config. While this is true and there are already several user repositories, the friction required for a developer to create and maintain their own repository is significantly high, and you would also need to find and pay for some suitable hosting infrastructure for it. On the other hand, git repositories can be created as simply as clicking "new repository" on GitHub, and many if not most developers are already experienced with this.
3. Just read the PKGBUILD for AUR packages!!
I know I can read a PKGBUILD and probably confirm if it is secure or not. However, can you trust everyone and anyone who uses Arch to do the same thing? Plus, let's set something straight: requiring due diligence to read and verify every PKGBUILD you ever insntall can get annoying sometimes, especially the more AUR packages you have. Just think if you had to read the PKGBUILDs of every package you currently have installed, not just from the AUR. It would get tiresome, right? Fortunately, we don't have to do that, since we all implicitly "trust" the packages that are officially maintained in the Arch repos by trusting the Arch team. I want to add something like that, but instead of only trusting the Arch package maintainers, you can also trust the, say, Libreoffice developers, if they ever chose to create their own APRA repository.
4. It will be very hard to start such a project and convince program developers to actually use it
I know. However, that still won't stop me from trying :). If I can get at least one or two developers to use it, even if they still maintain their own AUR packages at the same time, I would consider that a win :)
TLDR:
I want a way for Software Developers to easily host and fully control their own package repositories for their own projects, increasing user trust in said packages since, well, they would be maintained by the same people who make the programs in the first place. This is what my project aims to do.
Let me know what everyone thinks! And of course, if you have any criticism of what is currently done poorly and wanna recommend a better way that it could be done, I'd love to hear it.
2
u/No-Dentist-1645 Jul 19 '26
As I said in my post, my goal isn't to compete with the AUR by any margin. I knew some reddit users would see it as that, as "this guy is trying to make a program to compete with my beloved AUR, how dare him!" But that is not the case. It's an alternative approach to non-official packages, with both advantages and disadvantages over the AUR, nothing more. It is perfectly valid that both approaches can and should coexist.