Self-hostable Pacman repository server
 
 
Go to file
Jef Roosens 064bebd5c7
ci/woodpecker/push/build Pipeline failed Details
ci/woodpecker/push/clippy Pipeline failed Details
ci/woodpecker/push/lint Pipeline was successful Details
ci/woodpecker/pr/build Pipeline failed Details
chore(ci): bump rust version
2024-07-07 10:53:16 +02:00
.woodpecker chore(ci): bump rust version 2024-07-07 10:53:16 +02:00
libarchive feat: further work on new repo & package implementation 2024-05-25 13:31:46 +02:00
libarchive3-sys feat(libarchive): added FileWritter, also apparently formatted sys 2023-07-13 16:39:52 +02:00
server feat: use pretty package filenames parsed using regex 2024-07-06 22:06:09 +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 2023-08-04 21:35:45 +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: add Dockerfile & ci for publishing dev images 2023-08-05 12:23:15 +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
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".