APRI: Create and manage your own "AUR"-like package indexes!

AmmoniumX · Yesterday 02:12:27

Hello all,

I am ready to share the initial version of a project I've been working on during my free time.

It is called APRI, which stands for Arch Personal Repository Indexes. The main idea is that it is a developer tool that can allow software developers to maintain and, most importantly, directly own and moderate PKGBUILDs for their own projects, and that users can easily install packages from them. This is achieved by creating your own "package repository index" as a git repo; it is very similar in functionality to the AUR so developers will already be familiar to it: each branch is its own "package", containing a .SRCINFO and a PKGBUILD file. The apri CLI tool can then search these repositories and allow your users to install them. Think Ubuntu/Debian PPAs, minus all the infrastructure burden from them.

Example

A user can add your repository to their yaml config as such:

remotes:
  - name: ammoniumx
    url: https://github.com/AmmoniumX/APRA-Repo.git

This just adds the git repo to the list of "indexes". You can check it out, it contains one branch, "hellocpp-git", with .SRCINFO and PKGBUILD files to instruct how to install them. Then, once the repo is added to the config, a user can use the command apri -Syu hellocpp-git and it will pull the latest version of the branch and install it. It mimics the pacman -S, -Sy, -Su, and -Syu flags and will wrap the same operations over pacman by default unless --no-pacman is specified.

Target Audience and differences from AUR/User Repositories

The target audience for this project is software developers who want direct control over their own PKGBUILDs. Imagine developer "cooldev" is the maintainer of the software "libfoo" and many other packages. Now, cooldev can have a "cooldev/APRI" repository of their own, where they can host PKGBUILDs for libfoo and their other projects. They have full control over them, they control who is allowed to commit changes to it, and they can endorse this as a "blessed" installation method: if they were concerned that the AUR could have their packages orphaned after they lose interest and picked up by a different user, that is no longer an issue.

This project isn't meant as a "competitor" or "replacement" for the AUR or User Repositories: rather, it is a different thing with different priorities and design choices. User Repositories are a thing and they're great, but they require infrastructure and maintenance by the developer; on the other hand, APRI just requires a git repository, which is free to host on many git forges. The AUR is the most popular central repository for user-contributed packages, but as we all know, the packages can be authored and maintained by any user, not necessarily the software developer. While this is in some aspects a great thing, it allows way more packages to be created than they would if we only allowed the software developers themselves to create them, it also brings some trust concerns towards end users, and some software developers may feel uncomfortable to recomment the AUR package as an "official" distribution medium. Sure, the authors could maintain the AUR package themselves, but this puts them in a position of liability, where if they eventually lose interest in maintaining the package, it can be orphaned and picked up by anyone, resurfacing the trust concerns. These are all intentional design choices made by the AUR to allow packages to grow and survive even after the original maintainer loses interest, and it's a good thing that the AUR exists; that being said, some users may have differing priorities, and would rather have a closed ecosystem of "trusted" repositories. I believe that, at the very least, an alternative should exist, even if just for the sake of just having the choice.

---

Please let me know what everyone thinks and if there's an interest on me continuing this idea! This project is currently just an experiment to see if such an idea is worth pursuing: it is usable, offers the intended repository indexing/fetching/updating features as well as wrapping over pacman, but it is still in early stages, and some features such as dependency resolution within repositories are still planned. The code is available at https://github.com/AmmoniumX/APRI/

seth · Yesterday 05:44:55

The target audience for this project is software developers who want direct control over their own PKGBUILDs.

Why would they not just ship them w/ the sources, so instead of "configure/cmake; make; make install" the user runs "makepkg" in the source directory?

The only use-case here would be users saying "I blindly trust seth and loqs they have a bunch of PKGBUILDs in some github repos, so I can fetch and build them from there" what fails at the "I blindly trust seth" stage because from what I hear, he's quite some unstable asshole who might turn around and prank you just for the lolz.

Ftr, https://www.reddit.com/r/archlinux/comm … rustbased/

AmmoniumX · Yesterday 05:55:50

seth wrote:

The target audience for this project is software developers who want direct control over their own PKGBUILDs.
Why would they not just ship them w/ the sources, so instead of "configure/cmake; make; make install" the user runs "makepkg" in the source directory?
The only use-case here would be users saying "I blindly trust seth and loqs they have a bunch of PKGBUILDs in some github repos, so I can fetch and build them from there" what fails at the "I blindly trust seth" stage because from what I hear, he's quite some unstable asshole who might turn around and prank you just for the lolz.
Ftr, https://www.reddit.com/r/archlinux/comm … rustbased/

Yes, that is the exact use case, for when you trust X developer and want to use their repos. As an example, assume you want to install a compositor like Niri or whatever. If their dev wanted to, they can host their own repository, so that people can directly download their own software. You already trust the developer enough to use their software, might as well trust them to package the stuff too. That's the logic behind it. It's not for "random" users and trusting "random" repositories, but for developers you are already trusting

I also plan to support the "PKGBUILD shipped directly in the source" approach soon. The idea is to have both of them available to developers so they can choose whichever method they prefer, and "repositories" have the advantage that they don't necessarily have to be on the source

cyyynthia · Yesterday 12:25:30

I'm in the process of packaging my system configuration as a collection of Arch packages in a Git repository, which is a convenient way to share my config across systems. I like to think of it as an Arch-native, KISS, sane version of whatever Nix is doing that still lets me actually use my system, install stuff and tweak things on-the-fly without having to endure a sacrificial ritual and waste my time trying to make a circle fit in a square hole.

I'm using Paru for all my package management needs, which has built-in support for using git repositories as a package repository; see paru.conf(5). At first glance, it seems that it already does what your project implements with the added benefit of being an established tool that integrates these ad-hoc repositories to everyday system maintenance tasks.

Lone_Wolf · Yesterday 12:38:24

I know some developers that I do trust to write quality code. Unfortunately the majority of them doesn't run archlinux and have very little experience with packaging software .

They usually can manage producing a generic tarball or flatpak, but that's it. They'd need lots of help to write/maintain a good PKGBUILD.

seth · Yesterday 14:19:21

Yes, that is the exact use case, for when you trust X developer and want to use their repos.

So how is this different from filtering eg. https://aur.archlinux.org/packages?K=anthraxx&SeB=m ?

AmmoniumX · Yesterday 14:35:11

cyyynthia wrote:

I'm using Paru for all my package management needs, which has built-in support for using git repositories as a package repository; see paru.conf(5). At first glance, it seems that it already does what your project implements with the added benefit of being an established tool that integrates these ad-hoc repositories to everyday system maintenance tasks.

Yes, this is probably the most functionally similar thing to what I am working on. Tbh I didnt know paru supported PKGBUILD git repositories like that, that's a genuinely useful feature.

Arch Linux

#1 Yesterday 02:12:27