51 lines
1.3 KiB
Markdown
51 lines
1.3 KiB
Markdown
---
|
|
weight: 10
|
|
---
|
|
|
|
# Server
|
|
|
|
The server is the implementation of the repository.
|
|
|
|
```sh
|
|
vieter server
|
|
```
|
|
|
|
starts the HTTP server. Its endpoints are listed [here](/api).
|
|
|
|
## Multiple repositories
|
|
|
|
Vieter can contain multiple repositories, each of which is further divided into
|
|
various architectures.
|
|
|
|
A repository is created once a package archive is published to it using [this
|
|
route](/api#post-repopublish):
|
|
|
|
```sh
|
|
curl -XPOST -H "X-API-KEY: your-key" -T some-package.pkg.tar.zst https://example.com/somerepo/publish
|
|
```
|
|
|
|
This repository can then be added to Pacman as
|
|
described below.
|
|
|
|
## Pacman
|
|
|
|
A Vieter repository can be added to Pacman like any other repository. In your
|
|
`/etc/pacman.conf` file, add the following lines:
|
|
|
|
```
|
|
[vieter]
|
|
Server = https://example.com/$repo/$arch
|
|
SigLevel = Optional
|
|
```
|
|
|
|
Here, you see two important placeholder variables which get replaced by Pacman
|
|
when reading the file. `$repo` is replaced by the name within the square
|
|
brackets, which in this case would be `vieter`. `$arch` is replaced by the
|
|
output of `uname -m`. Because Vieter supports multiple repositories &
|
|
architectures per repository, using this notation makes sure you always use the
|
|
correct endpoint for fetching files.
|
|
|
|
I recommend placing this below all other repository entries, as the order
|
|
decides which repository gets used if there's ever a naming conflict.
|
|
|