Jef Roosens e3b0f4f0a1 | ||
---|---|---|
.woodpecker | ||
libarchive | ||
libarchive3-sys | ||
server | ||
.dockerignore | ||
.gitignore | ||
CHANGELOG.md | ||
Cargo.lock | ||
Cargo.toml | ||
Dockerfile | ||
LICENSE | ||
README.md | ||
docker-compose.yml |
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".