39 lines
1.7 KiB
Markdown
39 lines
1.7 KiB
Markdown
# 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".
|