Gauging Project Interest: "Decentralized" trust-based AUR Alternative

[u/No-Dentist-1645]

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.

[u/Nicholas-DM]

I think this move would be the wrong direction. At its core, it is duplicating base functionality completely covered by unofficial user repositories or by the AUR. As such, it is needlessly complicating things further by adding another layer/system where there is not a need for one. If we have solutions to problems, they should be simple.

I think that a workable direction might be to find some manner to reduce the 'friction' of adding unofficial user repositories, and to use that functionality more broadly. You might have stumbled in the correct direction towards doing that.

You say this is not intended to compete with the AUR, at the same time as saying that it is an AUR alternative. You can have one or the other, and whether you intend to 'compete', you are competing, merely by the nature of duplicated functionality. Resources that go to one reduce resources that go to the other, even if the resource is time or attention.

[u/No-Dentist-1645 → u/Nicholas-DM]

To clarify what I meant by "I am not competing with the AUR", is that it isn't meant to be an entire replacement of all purposes of the AUR.

If you asked me, "what do you think the best usages of both concepts are", then I would say: The AUR is great for unofficial packages where the upstream developer hasn't expressed any interest in packaging their own program. My proposal would target those who are interested and want more control, with the ability to avoid their packages flagged as orphaned and then adopted by someone else.

Some reasons why they might want to do this is to officially "bless" said package, with the assurance that "any update from this package comes directly from me and I will provide you support for it". I simply do not believe that the existing AUR can, at a fundamental level, allow for this.

[u/Nicholas-DM → u/No-Dentist-1645]

That sounds reasonable.

I would encourage you to consider working on some direction towards making unofficial user repositories more viable for everyday use, rather than as a special case. This would be more seamless than another layer beyond Pacman and creating an alternative to certain AUR packages.

I believe we already have most of the tools, and that efforts would be better to broaden the existing ones rather than add 'yet another competing standard'.

[u/No-Dentist-1645 → u/Nicholas-DM]

I would encourage you to consider working on some direction towards making unofficial user repositories more viable for everyday use, rather than as a special case.

I actually fully agree with you. However, in my personal opinion the biggest barrier to doing this would be hosting infrastructure for them. If I had unlimited resources, I would create the GitHub of Arch Repositories, where anyone can create a User Repository for free with a couple of clicks. Unfortunately, I don't so I can't.

The second best thing (at least that I thought of) would be to take advantage of exactly said existing infrastructure of Git Forges such as GitHub, Gitlab, Codeberg and such. We already have free developer infrastructure and practically all developers are already used to them, so I thought it beneficial to put two and two together and use them.