Plemya-x/ALR-Wiki
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Добавление документации

Browse Source
This commit is contained in:
Евгений Храмов 2024-08-26 17:26:10 +03:00
parent b0b23c6738
commit 6bd56caf7f
8 changed files with 817 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
.gitignore vendored Normal file
View File

@ -0,0 +1 @@
.idea

9
Home.md
View File

@ -1 +1,8 @@
Добро пожаловать в WIKI
# ALR Docs
- [Конфигурирование](configuration.md)
- [Использование](usage.md)
- [Пакеты](packages)
- [Скрипт сборки](packages/build-scripts.md)
- [Правила упаковки](packages/conventions.md)
- [Добавление пакетов в ALR-repo](packages/adding-packages.md)

44
configuration.md Normal file
View File

@ -0,0 +1,44 @@
# Configuration
На этой странице описана конфигурация ALR
---
## Оглавление
- [Конфигурационный файл](#config-file)
- [rootCmd](#rootcmd)
- [repo](#repo)
---
## Расположение файлов
| Путь | Описание
| --: | :--
| ~/.config/alr/alr.toml | Конфигурационный файл
| ~/.cache/alr/pkgs | Здесь создаются и хранятся пакеты
| ~/.cache/alr/repo | Репозитории git со всеми файлами `alr.sh`
| | Пример: `~/.cache/alr/repo/default/alr-git/alr.sh`
---
## Конфигурационный файл
### rootCmd
Поле "rootCmd" указывает, какую команду следует использовать для повышения привилегий. Значение по умолчанию - `sudo`.
### repo
Массив `repo` определяет, какие репозитории будут добавлены в ALR. У каждого репозитория должны быть имя и URL-адрес. В конфигурации репозиторий выглядит следующим образом:
```toml
[[repo]]
name = 'default'
url = 'https://gitflic.ru/project/xpamych/xpamych-alr-repo.git'
```
Репозиторий `defatult` добавляется по умолчанию. Может быть добавлено любое количество репозиториев.
---

5
packages/README.md Normal file
View File

@ -0,0 +1,5 @@
# LURE Docs > Packages
- [Build Scripts](build-scripts.md)
- [Package Conventions](conventions.md)
- [Adding Packages to LURE's repo](adding-packages.md)

19
packages/adding-packages.md Normal file
View File

@ -0,0 +1,19 @@
# Добавление пакетов для репозитория ALR
## Зависимости
- `go` (1.18+)
- `git`
- `go install mvdan.cc/sh/v3/cmd/shfmt@latest`
---
## Как протестировать пакет
Чтобы протестировать пакеты, вы можете сначала создать [файл оболочки `alr.sh`](./build-scripts.md), а затем запустить команду `alr build` для сборки локального файла `alr.sh` в пакет для вашего дистрибутива (подробнее о команде `build` [здесь]).(./usage.md#сборка)). Затем вы можете установить этот файл в свой дистрибутив и протестировать его.
## Как отправить пакет
Репозиторий ALR размещен на Github по адресу https://gitea.plemya-x.ru/xpamych/xpamych-alr-repo. В нем есть несколько каталогов, каждый из которых содержит файл "alr.sh`. Чтобы добавить пакет в репозиторий ALR, просто создайте PR с помощью [build script](./build-scripts.md) и поместите его в каталог с тем же именем, что и у пакета.
Как только ваш PR будет объединен, ALR откроет измененный репозиторий, и ваш пакет будет доступен для установки пользователям.

499
packages/build-scripts.md Normal file
View File

@ -0,0 +1,499 @@
# alr Build Scripts
alr uses build scripts similar to the AUR's PKGBUILDs. This is the documentation for those scripts.
---
## Table of Contents
- [Distro Overrides](#distro-overrides)
- [Variables](#variables)
- [name](#name)
- [version](#version)
- [release](#release)
- [epoch](#epoch)
- [desc](#desc)
- [homepage](#homepage)
- [maintainer](#maintainer)
- [architectures](#architectures)
- [licenses](#licenses)
- [provides](#provides)
- [conflicts](#conflicts)
- [deps](#deps)
- [build_deps](#build_deps)
- [opt_deps](#opt_deps)
- [replaces](#replaces)Все скрипты, отправленные в репозиторий ALR, должны быть отформатированы с помощью `shfmt`. Если они отформатированы неправильно, Github Actions добавит предложения на вкладке "Измененные файлы" в PR.
- [sources](#sources)
- [checksums](#checksums)
- [backup](#backup)
- [scripts](#scripts)
- [Functions](#functions)
- [prepare](#prepare)
- [version](#version-1)
- [build](#build)
- [package](#package)
- [Environment Variables](#environment-variables)
- [DISTRO_NAME](#distro_name)
- [DISTRO_PRETTY_NAME](#distro_pretty_name)
- [DISTRO_ID](#distro_id)
- [DISTRO_VERSION_ID](#distro_version_id)
- [ARCH](#arch)
- [NCPU](#ncpu)
- [Helper Commands](#helper-commands)
- [install-binary](#install-binary)
- [install-systemd](#install-systemd)
- [install-systemd-user](#install-systemd-user)
- [install-config](#install-config)
- [install-license](#install-license)
- [install-completion](#install-completion)
- [install-manual](#install-manual)
- [install-desktop](#install-desktop)
- [install-library](#install-library)
- [git-version](#git-version)
---
## Distro Overrides
Allowing alr to run on different distros provides some challenges. For example, some distros use different names for their packages. This is solved using distro overrides. Any variable or function used in a alr build script may be overridden based on distro and CPU architecture. The way you do this is by appending the distro and/or architecture to the end of the name. For example, [ITD](https://gitea.elara.ws/Elara6331/itd) depends on the `pactl` command as well as DBus and BlueZ. These are named somewhat differently on different distros. For ITD, I use the following for the dependencies:
```bash
deps=('dbus' 'bluez' 'pulseaudio-utils')
deps_arch=('dbus' 'bluez' 'libpulse')
deps_opensuse=('dbus-1' 'bluez' 'pulseaudio-utils')
```
Appending `arch` and `opensuse` to the end causes alr to use the appropriate array based on the distro. If on Arch Linux, it will use `deps_arch`. If on OpenSUSE, it will use `deps_opensuse`, and if on anything else, it will use `deps`.
Names are checked in the following order:
- $name_$architecture_$distro
- $name_$distro
- $name_$architecture
- $name
Distro detection is performed by reading the `/usr/lib/os-release` and `/etc/os-release` files.
### Like distros
Inside the `os-release` file, there is a list of "like" distros. alr takes this into account. For example, if a script contains `deps_debian` but not `deps_ubuntu`, Ubuntu builds will use `deps_debian` because Ubuntu is based on debian.
Most specificity is preferred, so if both `deps_debian` and `deps_ubuntu` is provided, Ubuntu and all Ubuntu-based distros will use `deps_ubuntu` while Debian and all Debian-based distros
that are not Ubuntu-based will use `deps_debian`.
Like distros are disabled when using the `alr_DISTRO` environment variable.
## Variables
Any variables marked with `(*)` are required
### name (*)
The `name` variable contains the name of the package described by the script.
### version (*)
The `version` variable contains the version of the package. This should be the same as the version used by the author upstream.
Versions are compared using the [rpmvercmp](https://fedoraproject.org/wiki/Archive:Tools/RPM/VersionComparison) algorithm.
### release (*)
The `release` number is meant to differentiate between different builds of the same package version, such as if the script is changed but the version stays the same. The `release` must be an integer.
### epoch
The `epoch` number forces the package to be considered newer than versions with a lower epoch. It is meant to be used if the versioning scheme can't be used to determine which package is newer. Its use is discouraged and it should only be used if necessary. The `epoch` must be a positive integer.
### desc
The `desc` field contains the description for the package. It should not contain any newlines.
### homepage
The `homepage` field contains the URL to the website of the project packaged by this script.
### maintainer
The `maintainer` field contains the name and email address of the person maintaining the package. Example:
```text
Elara Musayelyan <elara@elara.ws>
```
While alr does not require this field to be set, Debian has deprecated unset maintainer fields, and may disallow their use in `.deb` packages in the future.
### architectures
The `architectures` array contains all the architectures that this package supports. These match Go's GOARCH list, except for a few differences.
The `all` architecture will be translated to the proper term for the packaging format. For example, it will be changed to `noarch` if building a `.rpm`, or `any` if building an Arch package.
Since multiple variations of the `arm` architecture exist, the following values should be used:
`arm5`: armv5
`arm6`: armv6
`arm7`: armv7
alr will attempt to detect which variant your system is using by checking for the existence of various CPU features. If this yields the wrong result or if you simply want to build for a different variant, the `alr_ARM_VARIANT` variable should be set to the ARM variant you want. Example:
```shell
alr_ARM_VARIANT=arm5 alr install ...
```
### licenses
The `licenses` array contains the licenses used by this package. In order to standardize license names, values should be [SPDX Identifiers](https://spdx.org/licenses/) such as `Apache-2.0`, `MIT`, and `GPL-3.0-only`. If the project uses a license that is not standardized in SPDX, use the value `Custom`. If the project has multiple nonstandard licenses, include `Custom` as many times as there are nonstandard licenses.
### provides
The `provides` array specifies what features the package provides. For example, if two packages build `ffmpeg` with different build flags, they should both have `ffmpeg` in the `provides` array.
### conflicts
The `conflicts` array contains names of packages that conflict with the one built by this script. If two different packages contain the executable for `ffmpeg`, they cannot be installed at the same time, so they conflict. The `provides` array will also be checked, so this array generally contains the same values as `provides`.
### deps
The `deps` array contains the dependencies for the package. alr repos will be checked first, and if the packages exist there, they will be built and installed. Otherwise, they will be installed from the system repos by your package manager.
### build_deps
The `build_deps` array contains the dependencies that are required to build the package. They will be installed before the build starts. Similarly to the `deps` array, alr repos will be checked first.
### opt_deps
The `opt_deps` array contains optional dependencies for the package. A description can be added after ": ", but it's not required.
```bash
opt_deps_arch=(
'git: Download git repositories'
'aria2: Download files'
)
```
### replaces
The `replaces` array contains the packages that are replaced by this package. Generally, if package managers find a package with a `replaces` field set, they will remove the listed package(s) and install that one instead. This is only useful if the packages are being stored in a repo for your package manager.
### sources
The `sources` array contains URLs which are downloaded into `$srcdir` before the build starts.
If the URL provided is an archive or compressed file, it will be extracted. To disable this, add the `~archive=false` query parameter. Example:
Extracted:
```text
https://example.com/archive.tar.gz
```
Not extracted:
```text
https://example.com/archive.tar.gz?~archive=false
```
If the URL scheme starts with `git+`, the source will be downloaded as a git repo. The git download mode supports multiple parameters:
- `~rev`: Specify which revision of the repo to check out.
- `~depth`: Specify what depth should be used when cloning the repo. Must be an integer.
- `~name`: Specify the name of the directory into which the git repo should be cloned.
- `~recursive`: If set to true, submodules will be cloned recursively. It is false by default.
Examples:
```text
git+https://gitea.elara.ws/Elara6331/itd?~rev=resource-loading&~depth=1
```
```text
git+https://gitea.elara.ws/alr/alr?~rev=v0.0.1&~recursive=true
```
### checksums
The `checksums` array must be the same length as the `sources` array. It contains checksums for the source files. The files are checked against the checksums and the build fails if they don't match.
By default, checksums are expected to be sha256. To change the algorithm, add it before the hash with a colon in between. For example, `md5:bc0c6f5dcd06bddbca9a0163e4c9f2e1`. The following algorithms are currently supported: `sha256`, `sha224`, `sha512`, `sha384`, `sha1`, and `md5`.
To skip the check for a particular source, set the corresponding checksum to `SKIP`.
### backup
The `backup` array contains files that should be backed up when upgrading and removing. The exact behavior of this depends on your package manager. All files within this array must be full destination paths. For example, if there's a config called `config` in `/etc` that you want to back up, you'd set it like so:
```bash
backup=('/etc/config')
```
### scripts
The `scripts` variable contains a Bash associative array that specifies the location of various scripts relative to the build script. Example:
```bash
scripts=(
['preinstall']='preinstall.sh'
['postinstall']='postinstall.sh'
['preremove']='preremove.sh'
['postremove']='postremove.sh'
['preupgrade']='preupgrade.sh'
['postupgrade']='postupgrade.sh'
['pretrans']='pretrans.sh'
['posttrans']='posttrans.sh'
)
```
Note: The quotes are required due to limitations with the bash parser used.
The `preupgrade` and `postupgrade` scripts are only available in `.apk` and Arch Linux packages.
The `pretrans` and `posttrans` scripts are only available in `.rpm` packages.
The rest of the scripts are available in all packages.
---
## Functions
This section documents user-defined functions that can be added to build scripts. Any functions marked with `(*)` are required.
All functions are executed in the `$srcdir` directory
### version
The `version()` function updates the `version` variable. This allows for automatically deriving the version from sources. This is most useful for git packages, which usually don't need to be changed, so their `version` variable stays the same.
An example of using this for git:
```bash
version() {
cd "$srcdir/itd"
printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
}
```
The AUR equivalent is the [`pkgver()` function](https://wiki.archlinux.org/title/VCS_package_guidelines#The_pkgver()_function)
### prepare
The `prepare()` function is meant to prepare the sources for building and packaging. This is the function in which patches should be applied, for example, by the `patch` command, and where tools like `go generate` should be executed.
### build
The `build()` function is where the package is actually built. Use the same commands that would be used to manually compile the software. Often, this function is just one line:
```bash
build() {
make
}
```
### package (*)
The `package()` function is where the built files are placed into the directory that will be used by alr to build the package.
Any files that should be installed on the filesystem should go in the `$pkgdir` directory in this function. For example, if you have a binary called `bin` that should be placed in `/usr/bin` and a config file called `bin.cfg` that should be placed in `/etc`, the `package()` function might look like this:
```bash
package() {
install -Dm755 bin ${pkgdir}/usr/bin/bin
install -Dm644 bin.cfg ${pkgdir}/etc/bin.cfg
}
```
---
## Environment Variables
alr exposes several values as environment variables for use in build scripts.
### DISTRO_NAME
The `DISTRO_NAME` variable is the name of the distro as defined in its `os-release` file.
For example, it's set to `Fedora Linux` in a Fedora 36 docker image
### DISTRO_PRETTY_NAME
The `DISTRO_PRETTY_NAME` variable is the "pretty" name of the distro as defined in its `os-release` file.
For example, it's set to `Fedora Linux 36 (Container Image)` in a Fedora 36 docker image
### DISTRO_ID
The `DISTRO_ID` variable is the identifier of the distro as defined in its `os-release` file. This is the same as what alr uses for overrides.
For example, it's set to `fedora` in a Fedora 36 docker image
### DISTRO_ID_LIKE
The `DISTRO_ID_LIKE` variable contains identifiers of similar distros to the one running, separated by spaces.
For example, it's set to `opensuse suse` in an OpenSUSE Tumbleweed docker image and `rhel fedora` in a CentOS 8 docker image.
### DISTRO_VERSION_ID
The `DISTRO_VERSION_ID` variable is the version identifier of the distro as defined in its `os-release` file.
For example, it's set to `36` in a Fedora 36 docker image and `11` in a Debian Bullseye docker image
### ARCH
The `ARCH` variable is the architecture of the machine running the script. It uses the same naming convention as the values in the `architectures` array
### NCPU
The `NCPU` variable is the amount of CPUs available on the machine running the script. It will be set to `8` on a quad core machine with hyperthreading, for example.
---
## Helper Commands
alr provides various commands to help packagers create proper cross-distro packages. These commands should be used wherever possible instead of doing the tasks manually.
### install-binary
`install-binary` accepts 1-2 arguments. The first argument is the binary you'd like to install. The second is the filename that should be used.
If the filename argument is not provided, tha name of the input file will be used.
Examples:
```bash
install-binary ./itd
install-binary ./itd itd-2
```
### install-systemd
`install-systemd` installs regular systemd system services (see `install-systemd-user` for user services)
It accepts 1-2 arguments. The first argument is the service you'd like to install. The second is the filename that should be used.
If the filename argument is not provided, tha name of the input file will be used.
Examples:
```bash
install-systemd ./syncthing@.service
install-systemd-user ./syncthing@.service sync-thing@.service
```
### install-systemd-user
`install-systemd-user` installs systemd user services (services like `itd` meant to be started with `--user`).
It accepts 1-2 arguments. The first argument is the service you'd like to install. The second is the filename that should be used.
If the filename argument is not provided, tha name of the input file will be used.
Examples:
```bash
install-systemd-user ./itd.service
install-systemd-user ./itd.service infinitime-daemon.service
```
### install-config
`install-config` installs configuration files into the `/etc` directory
It accepts 1-2 arguments. The first argument is the config you'd like to install. The second is the filename that should be used.
If the filename argument is not provided, tha name of the input file will be used.
Examples:
```bash
install-config ./itd.toml
install-config ./itd.example.toml itd.toml
```
### install-license
`install-license` installs a license file
It accepts 1-2 arguments. The first argument is the config you'd like to install. The second is the filename that should be used.
If the filename argument is not provided, tha name of the input file will be used.
Examples:
```bash
install-license ./LICENSE itd/LICENSE
```
### install-completion
`install-completion` installs shell completions
It currently supports `bash`, `zsh`, and `fish`
Completions are read from stdin, so they can either be piped in or retrieved from files
Two arguments are required for this function. The first one is the name of the shell and the second is the name of the completion.
Examples:
```bash
./k9s completion fish | install-completion fish k9s
install-completion bash k9s <./k9s/completions/k9s.bash
```
### install-manual
`install-manual` installs manpages. It accepts a single argument, which is the path to the manpage.
The install path will be determined based on the number at the end of the filename. If a number cannot be extracted, an error will be returned.
Examples:
```bash
install-manual ./man/strelaysrv.1
install-manual ./mdoc.7
```
### install-desktop
`install-desktop` installs desktop files for applications. It accepts 1-2 arguments. The first argument is the config you'd like to install. The second is the filename that should be used.
If the filename argument is not provided, tha name of the input file will be used.
Examples:
```bash
install-desktop ./${name}/share/admc.desktop
install-desktop ./${name}/share/admc.desktop admc-app.desktop
```
### install-library
`install-library` installs shared and static libraries to the correct location.
This is the most important helper as it contains logic to figure out where to install libraries based on the target distro and CPU architecture. It should almost always be used to install all libraries.
It accepts 1-2 arguments. The first argument is the config you'd like to install. The second is the filename that should be used.
If the filename argument is not provided, tha name of the input file will be used.
Examples:
```bash
install-library ./${name}/build/libadldap.so
```
### git-version
`git-version` returns a version number based on the git revision of a repository.
If an argument is provided, it will be used as the path to the repo. Otherwise, the current directory will be used.
The version number will be the amount of revisions, a dot, and the short hash of the current revision. For example: `118.e4b8348`.
The AUR's convention includes an `r` at the beginning of the version number. This is ommitted because some distros expect the version number to start with a digit.
Examples:
```bash
git-version
git-version "$srcdir/itd"
```

36
packages/conventions.md Normal file
View File

@ -0,0 +1,36 @@
# Package Conventions
## General
Packages should have the name(s) of what they contain in their `provides` and `conflicts` arrays. That way, they can be installed by users without needing to know the full package name. For example, there are two alr packages for ITD: `itd-bin`, and `itd-git`. Both of them have provides and conflicts arrays specifying the two commands they install: `itd`, and `itctl`. This means that if a user wants to install ITD, they simply have to type `alr in itd` and alr will prompt them for which one they want to install.
## Binary packages
Packages that install download and install precompiled binaries should have a `-bin` suffix.
## Git packages
Packages that build and install programs from source code cloned directly from Git should have a `-git` suffix.
The versions of these packages should consist of the amount of revisions followed by the current revision, separated by a period. For example: `183.80187b0`. Note that unlike the AUR, there is no `r` at the beginning. This is because some package managers refuse to install packages whose version numbers don't start with a digit.
This version number can be obtained using the following command:
```bash
printf "%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
```
The `version()` function for such packages should use the alr-provided `git-version` helper command, like so:
```bash
version() {
cd "$srcdir/$name"
git-version
}
```
This uses alr's embedded Git implementation, which ensures that the user doesn't need Git installed on their system in order to install `-git` packages.
## Other packages
Packages that download sources for a specific version of a program should not have any suffix, even if those sources are downloaded from Git.

205
usage.md Normal file
View File

@ -0,0 +1,205 @@
# Использование
## Оглавление
- [Команды](#команды)
- [Установка](#install)
- [Удаление](#remove)
- [Обновление пакетов](#upgrade)
- [Информация](#info)
- [Список](#list)
- [Сборка](#build)
- [ДОбавление репозитория](#addrepo)
- [Удаление репозитория](#removerepo)
- [Обновление изменений](#refresh)
- [Исправление](#fix)
- [Версия](#version)
- [Переменные окружения](#environment-variables)
- [Дистрибутивы](#alr_distro)
- [Формат пакета](#alr_pkg_format)
- [Архитектура](#alr_arm_variant)
---
## команды
### install
Команда установки устанавливает пакет из репозиториев Alr. Любые пакеты, которых нет в репозиториях Alr, передаются в системный менеджер пакетов для установки.
Аргументы пакета не обязаны быть точными. Alr проверит массив и сообщит, если точное совпадение не найдено. Также поддерживается использование "%" в качестве замены.
Если найдено несколько пакетов, вы будете проинформированы о выборе пакета для установки.
По умолчанию, если пакет уже был собран, Alr установит кэшированный пакет вместо пересобирания. Используйте флаг -c или --clean, чтобы принудительно пересобрать пакет.
Примеры:
```shell
alr in alr-bin # найдёт только alr-bin
alr in alr # finds alr-bin and alr-git
alr in it% # finds alr-bin, alr-git, and itgui-git
alr in -c alr-bin
```
### remove
The remove command is for convenience. All it does is forwards the remove command to the system package manager.
Example:
```shell
alr rm firefox
```
### upgrade
The upgrade command looks through the packages installed on your system and sees if any of them match alr repo packages. If they do, their versions are compared using the `rpmvercmp` algorithm. If alr repos contain a newer version, the package is upgraded.
By default, if a package has already been built, alr will install the cached package rather than re-build it. Use the `-c` or `--clean` flag to force a re-build.
Example:
```shell
alr up
```
### info
The info command displays information about a package in alr's repos.
The package arguments do not have to be exact. alr will check the `provides` array if an exact match is not found. There is also support for using "%" as a wildcard.
If multiple packages are found, you will be prompted to select which you want to show.
Example:
```shell
alr info alr-bin # only finds alr-bin
alr info alr # finds alr-bin and alr-git
alr info it% # finds alr-bin, alr-git, and itgui-git
```
### list
The list command lists all alr repo packages as well as their versions
This command accepts a single optional argument. This argument is a pattern to filter found packages against.
The pattern does not have to be exact. alr will check the `provides` array if an exact match is not found. There is also support for using "%" as a wildcard.
There is a `-I` or `--installed` flag that filters out any packages that are not installed on the system
Examples:
```shell
alr ls # lists all alr packages
alr ls -I # lists all installed packages
alr ls i% # lists all packages starting with "i"
alr ls %d # lists all packages ending with "d"
alr ls -I i% # lists all installed packages that start with "i"
```
### build
The build command builds a package using a `alr.sh` build script in the current directory. The path to the script can be changed with the `-s` flag.
Example:
```shell
alr build
```
### addrepo
The addrepo command adds a repository to alr if it doesn't already exist. The `-n` flag sets the name of the repository, and the `-u` flag is the URL to the repository. Both are required.
Example:
```shell
alr ar -n default -u https://github.com/Elara6331/alr-repo
```
### removerepo
The removerepo command removes a repository from alr and deletes its contents if it exists. The `-n` flag specifies the name of the repo to be deleted.
Example:
```shell
alr rr -n default
```
### refresh
The refresh command pulls all changes from all alr repos that have changed.
Example:
```shell
alr ref
```
### fix
The fix command attempts to fix issues with alr by deleting and rebuilding alr's cache
Example:
```shell
alr fix
```
### version
The version command returns the current alr version and exits
Example:
```shell
alr version
```
---
## Environment Variables
### alr_DISTRO
The `alr_DISTRO` environment variable should be set to the distro for which the package should be built. It tells alr which overrides to use. Values should be the same as the `ID` field in `/etc/os-release` or `/usr/lib/os-release`. Possible values include:
- `arch`
- `alpine`
- `opensuse`
- `debian`
### alr_PKG_FORMAT
The `alr_PKG_FORMAT` environment variable should be set to the packaging format that should be used. Valid values are:
- `archlinux`
- `apk`
- `rpm`
- `deb`
### alr_ARM_VARIANT
The `alr_ARM_VARIANT` environment variable dictates which ARM variant to build for, if alr is running on an ARM system. Possible values include:
- `arm5`
- `arm6`
- `arm7`
---
## Cross-packaging for other Distributions
You can create packages for different distributions
setting the environment variables `alr_DISTRO` and `alr_PKG_FORMAT` as mentioned above.
Examples:
```
alr_DISTRO=arch alr_PKG_FORMAT=archlinux alr build
alr_DISTRO=alpine alr_PKG_FORMAT=apk alr build
alr_DISTRO=opensuse alr_PKG_FORMAT=rpm alr build
alr_DISTRO=debian alr_PKG_FORMAT=deb alr build
```
---