docs: started terminology page

docs
Jef Roosens 2023-01-03 17:20:40 +01:00
parent 8a0214babe
commit 1f4b89f820
Signed by: Jef Roosens
GPG Key ID: B75D4F293C7052DB
2 changed files with 42 additions and 2 deletions

View File

@ -10,8 +10,9 @@ documentation might not be relevant anymore for the latest release.
## Overview
Vieter consists of two main parts, namely an implementation of an Arch
repository server & a scheduling system to periodically build Pacman packages &
publish them to a repository.
repository server & an accompanying build system for populating said repository
by periodically building packages. Package builds happen in isolated Docker
containers.
{{< hint info >}}
**Note**

View File

@ -0,0 +1,39 @@
---
weight: 40
---
# Terminology
Throughout both the codebase and the documentation, I use a couple of terms
that might be confusing at first glance. This page aims to explain this
Vieter-specific jargon.
## Repo & arch-repo
In Pacman jargon, a repository is simply an HTTP(S) web server that provides a
database archive, and optionally a files archive. This database archive
contains information about what packages are contained in the repository,
including the filenames of the actual package tarballs that Pacman then
downloads when installing and updating packages.
In Vieter, this is called an arch-repository. The reason for this change in
naming is because Vieter allows packages of different architectures to reside
under the same repository name. For a Vieter repository named `vieter`, there
can be packages built for the `x86_64` and the `aarch64` architecture. For both
of these architectures, a Pacman repository (or arch-repository) is created,
and it's these architecture-specific repositories that are then accessed by
Pacman. On either architecture, the repository could then be added to
`/etc/pacman.conf` as follows:
```
[vieter]
Server = https://arch.r8r.be/$repo/$arch
SigLevel = Optional
```
## Target
A target describes a build that should be periodically performed. Each target
consists of a URL to a Git repository containing a PKGBUILD (or a direct URL to
said PKGBUILD), among various other configuration options. The list of targets
defines what builds need to be performed at what times, on what architectures.