Self-hostable Pacman repository server
 
 
Go to file
Jef Roosens fbdb182f50
ci/woodpecker/tag/build-rel Pipeline was successful Details
ci/woodpecker/tag/docker Pipeline was successful Details
ci/woodpecker/push/build-rel Pipeline was successful Details
ci/woodpecker/push/lint Pipeline was successful Details
ci/woodpecker/push/docker Pipeline was successful Details
chore: update changelog for 0.1.0
2024-07-09 21:13:55 +02:00
.woodpecker chore: update changelog for 0.1.0 2024-07-09 21:13:55 +02:00
libarchive chore: fix all clippy warnings 2024-07-08 22:12:46 +02:00
libarchive3-sys chore: fix all clippy warnings 2024-07-08 22:12:46 +02:00
server chore(repo): remove package removal route for now 2024-07-09 20:46:51 +02:00
.dockerignore chore: add Dockerfile & ci for publishing dev images 2023-08-05 12:23:15 +02:00
.gitignore fix: commit lock file 2023-07-16 17:47:54 +02:00
CHANGELOG.md chore: update changelog for 0.1.0 2024-07-09 21:13:55 +02:00
Cargo.lock feat: use pretty package filenames parsed using regex 2024-07-06 22:06:09 +02:00
Cargo.toml feat(server): pagination 2023-08-02 22:19:55 +02:00
Dockerfile chore: chmod binary in dockerfile 2024-07-09 17:46:38 +02:00
LICENSE Initial commit 2023-06-27 10:21:43 +02:00
README.md feat: re-implement package remove route 2024-05-29 09:58:19 +02:00
build.Dockerfile feat(ci): use custom builder image 2024-07-07 13:35:45 +02:00
docker-compose.yml chore: add Dockerfile & ci for publishing dev images 2023-08-05 12:23:15 +02:00

README.md

Rieter

Rieter is both a Pacman repository server, as well as a build system for Pacman packages.

Goals

Repository server

My first goal for this project is to create a convenient all-round repository server implementation that could be used for everything from self-hosting a local repository to managing an entire distribution's package repository. It should be easy to deploy, lightweight, and work with any distribution. It should support any number of repositories and packages, and work with any package architecture.

The repositories can be populated by manually uploading packages to the server (e.g. from a CI build), or by mirroring already existing repositories. The mirroring feature in particular makes it trivial to set up a new mirror for a distribution, as the server would take care of keeping the mirror up-to-date. Another usecase for this would be creating a local mirror of your distribution's repositories, which can greatly reduce your update times depending on your internet connection.

Most users however don't need a full copy of a distro's package repository, so Rieter also provides a "smart mirror" mode. In this mode, a Rieter instance only syncs packages that have been requested before, e.g. from a previous system update. This way, your updates will still be a lot faster as the required packages are cached, but packages you don't use don't get stored, saving you a lot of storage space.

Build system

The second goal is to create an easy-to-use build system for Pacman packages. This could for example be used to automatically build AUR packages and publish them to one of your repositories. This can greatly reduce update times, as you no longer need to build AUR packages locally, as this automatically happens "in the cloud".