Исправление страниц Wiki
This commit is contained in:
parent
6bd56caf7f
commit
348b449ea3
3
.gitignore
vendored
3
.gitignore
vendored
@ -1 +1,2 @@
|
||||
.idea
|
||||
.idea
|
||||
.gigaide
|
||||
7
Home.md
7
Home.md
@ -2,7 +2,6 @@
|
||||
|
||||
- [Конфигурирование](configuration.md)
|
||||
- [Использование](usage.md)
|
||||
- [Пакеты](packages)
|
||||
- [Скрипт сборки](packages/build-scripts.md)
|
||||
- [Правила упаковки](packages/conventions.md)
|
||||
- [Добавление пакетов в ALR-repo](packages/adding-packages.md)
|
||||
- [Пакеты]()
|
||||
- [Добавление пакетов для репозитория ALR](addpackage.md)
|
||||
- [Сборочный скрипт](build-scripts.md)
|
||||
26
addpackage.md
Normal file
26
addpackage.md
Normal file
@ -0,0 +1,26 @@
|
||||
# Добавление пакетов в основной репозиторий
|
||||
---
|
||||
- [Зависимости](#зависимости)
|
||||
- [Как протестировать пакет](#как-протестировать-пакет)
|
||||
- [Как отправить пакет](#как-отправить-пакет)
|
||||
---
|
||||
|
||||
|
||||
## Зависимости
|
||||
|
||||
- `go` (1.18+)
|
||||
- `git`
|
||||
- `go install mvdan.cc/sh/v3/cmd/shfmt@latest`
|
||||
|
||||
---
|
||||
## Как протестировать пакет
|
||||
|
||||
Чтобы протестировать пакеты, вы можете сначала создать [Скрипт сборки `alr.sh`](#alr-скрипт-сборки), а затем запустить команду `alr build` для сборки локального файла `alr.sh` в пакет для вашего дистрибутива (подробнее о команде `build` [здесь](./usage.md#build)).
|
||||
|
||||
Затем вы можете установить этот файл обычным способом в свой дистрибутив и протестировать его.
|
||||
|
||||
## Как отправить пакет
|
||||
|
||||
Репозиторий ALR размещен на Github по адресу https://gitea.plemya-x.ru/xpamych/xpamych-alr-repo. В нем есть несколько каталогов, каждый из которых содержит файл `alr.sh`. Чтобы добавить пакет в репозиторий ALR, просто создайте PR с помощью [build script](./build-scripts.md) и поместите его в каталог с тем же именем, что и у пакета.
|
||||
|
||||
Как только ваш PR будет объединен, ALR откроет измененный репозиторий, и ваш пакет будет доступен для установки пользователям ALR.
|
||||
458
build-scripts.md
Normal file
458
build-scripts.md
Normal file
@ -0,0 +1,458 @@
|
||||
# ALR скрипт сборки
|
||||
|
||||
ALR использует скрипты сборки, похожие на `PKGBUILD`'s *AUR*. Ниже описаны требования к содержимому.
|
||||
|
||||
---
|
||||
- [Переопределение дистрибутива](#переопределение-дистрибутива)
|
||||
- [Похожие дистрибутивы](#похожие-дистрибутивы)
|
||||
- [Переменные](#переменные)
|
||||
- [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](#release)
|
||||
- [sources](#sources)
|
||||
- [checksums](#checksums)
|
||||
- [backup](#backup)
|
||||
- [scripts](#scripts)
|
||||
- [Функции](#функции)
|
||||
- [prepare](#prepare)
|
||||
- [version](#version)
|
||||
- [build](#build)
|
||||
- [package](#package)
|
||||
- [Переменные окружения](#переменные-окружения)
|
||||
- [DISTRO_NAME](#distro_name)
|
||||
- [DISTRO_PRETTY_NAME](#distro_pretty_name)
|
||||
- [DISTRO_ID](#distro_id)
|
||||
- [DISTRO_VERSION_ID](#distro_version_id)
|
||||
- [ARCH](#arch)
|
||||
- [NCPU](#ncpu)
|
||||
- [Вспомогательные команды](#вспомогательные-команды)
|
||||
- [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)
|
||||
---
|
||||
|
||||
## Переопределение дистрибутива
|
||||
|
||||
Использование ALR в различных дистрибутивах представляет собой некоторые проблемы. Например, некоторые дистрибутивы используют разные названия для своих пакетов. Это решается с помощью переопределений дистрибутива. Любая переменная или функция, используемая в скрипте сборки ALR, может быть переопределена в зависимости от дистрибутива и архитектуры CPU. Сделать это можно, добавляя наименование дистрибутива и/или архитектуры в конец имени. Например, ALR зависит от пакета `go`. `Go` имеет несколько разные названия на различных дистрибутивах. Для ALR я использую следующее для зависимостей:
|
||||
```bash
|
||||
deps=('golang')
|
||||
deps_arch=('go' )
|
||||
deps_opensuse=('go')
|
||||
```
|
||||
Добавление `arch` и `opensuse` в конец заставляет ALR использовать соответствующий массив в зависимости от дистрибутива. Если вы находитесь на *Arch Linux*, он будет использовать `deps_arch`. Если на *OpenSUSE*, он будет использовать `deps_opensuse`, а если на что-то другое, то будет использовать `deps`.
|
||||
|
||||
Имена проверяются в следующем порядке:
|
||||
```sh
|
||||
$name_$architecture_$distro
|
||||
$name_$distro
|
||||
$name_$architecture
|
||||
$name
|
||||
```
|
||||
Обнаружение дистрибутива выполняется путем чтения файлов `/usr/lib/os-release` и `/etc/os-release`.
|
||||
|
||||
## Похожие дистрибутивы
|
||||
|
||||
Внутри файла `os-release` есть список "похожих" дистрибутивов. ALR учитывает это. Например, если скрипт содержит `deps_debian`, но не `deps_ubuntu`, сборки *Ubuntu* будут использовать `deps_debian`, поскольку *Ubuntu* основан на *Debian*.
|
||||
|
||||
Предпочтительна наибольшая спецификация, поэтому, если предоставлены как `deps_debian`, так и `deps_ubuntu`, *Ubuntu* и все основанные на нём дистрибутивы будут использовать `deps_ubuntu`, в то время как *Debian* и все основанные на нем дистрибутивы, которые не являются основанными на *Ubuntu*, будут использовать `deps_debian`.
|
||||
|
||||
Похожие дистрибутивы отключены при использовании переменной окружения alr_DISTRO.
|
||||
|
||||
## Переменные
|
||||
|
||||
Любые переменные, отмеченные (*), являются обязательными.
|
||||
### name*
|
||||
|
||||
Переменная `name` содержит имя пакета, описанного в скрипте (должно совпадать с наименованием каталога в репозитории который содержит скрипт сборки пакета ALR).
|
||||
|
||||
### version*
|
||||
|
||||
Переменная `version` содержит версию пакета. Это должно быть то же самое, что и версия, используемая автором в upstream.
|
||||
|
||||
Сравнение версий выполняется с использованием алгоритма `rpmvercmp`.
|
||||
|
||||
### release*
|
||||
|
||||
Номер `release` предназначен для различения различных сборок одной и той же версии пакета, например, если скрипт изменяется, но версия остается прежней. `release` должен быть целым числом.
|
||||
|
||||
### epoch
|
||||
|
||||
Номер `epoch` заставляет пакет считаться более новым, чем версии с меньшим номером `epoch`. Он должен использоваться, если схема нумерации не может быть использована для определения, какой пакет новее. Его использование не рекомендуется, и он должен использоваться только в случае необходимости. Номер `epoch` должен быть положительным целым числом.
|
||||
|
||||
### desc
|
||||
|
||||
Поле `desc` содержит описание пакета. Оно не должно содержать переносов строк.
|
||||
|
||||
### homepage
|
||||
|
||||
Поле `homepage` содержит URL-адрес сайта проекта, упакованного данным скриптом.
|
||||
|
||||
### maintainer
|
||||
|
||||
Поле `maintainer` содержит имя и адрес электронной почты человека, поддерживающего пакет. Пример:
|
||||
```text
|
||||
Евгений Храмов <xpamych@yandex.ru>
|
||||
```
|
||||
|
||||
Хотя ALR не требует установки этого поля, *Debian* отказался от неустановленных полей `maintainer` и может запретить их использование в пакетах .deb в будущем.
|
||||
|
||||
### architectures
|
||||
|
||||
Массив `architectures` содержит все архитектуры, которые поддерживает данный пакет. Они соответствуют списку `GOARCH` языка `Go`, за исключением некоторых отличий.
|
||||
|
||||
Архитектура `all` будет переведена на правильный термин для формата упаковки. Например, он будет изменен на `noarch`, если строится `.rpm`, или `any`, если строится пакет *Arch*.
|
||||
|
||||
Поскольку существует несколько вариантов архитектуры `arm`, должны использоваться следующие значения:
|
||||
```sh
|
||||
arm5: armv5
|
||||
arm6: armv6
|
||||
arm7: armv7
|
||||
```
|
||||
ALR попытается определить, какой вариант использует ваша система, проверяя существование различных функций `CPU`. Если это дает неправильный результат или если вы просто хотите собрать для другого варианта, переменная `alr_ARM_VARIANT` должна быть установлена в желаемый вариант `ARM`. Пример:
|
||||
```sh
|
||||
alr_ARM_VARIANT=arm5 alr install ...
|
||||
```
|
||||
|
||||
### licenses
|
||||
|
||||
Массив `licenses` содержит лицензии, используемые этим пакетом. Для стандартизации названий лицензий значения должны быть идентификаторами `SPDX` такими как `Apache-2.0`, `MIT` и `GPL-3.0-only`. Если проект использует лицензию, которая не стандартизирована в `SPDX`, используйте значение `Custom`. Если проект имеет несколько нестандартных лицензий, включите `Custom` столько раз, сколько есть нестандартных лицензий.
|
||||
|
||||
### provides
|
||||
|
||||
Массив `provides` указывает, какие функции предоставляет пакет. Например, если два пакета собирают `ffmpeg` с разными флагами сборки, оба должны иметь `ffmpeg` в массиве `provides`.
|
||||
|
||||
### conflicts
|
||||
|
||||
Массив `conflicts` содержит имена пакетов, которые конфликтуют с пакетом, собранным данным скриптом. Если два различных пакета содержат исполняемый файл для `ffmpeg`, их нельзя установить одновременно, поэтому они конфликтуют. Массив `provides` также будет проверяться, поэтому этот массив обычно содержит те же значения, что и `provides`.
|
||||
|
||||
### deps
|
||||
|
||||
Массив `deps` содержит зависимости для пакета. Репозитории ALR будут проверены первыми, и если пакеты существуют там, они будут собраны и установлены. В противном случае они будут установлены из системных репозиториев вашим менеджером пакетов.
|
||||
|
||||
### build_deps
|
||||
|
||||
Массив `build_deps` содержит зависимости, которые необходимы для сборки пакета. Они будут установлены перед началом сборки. Аналогично массиву `deps`, сначала будут проверены репозитории ALR.
|
||||
|
||||
### opt_deps
|
||||
|
||||
Массив `opt_deps` содержит необязательные зависимости для пакета. Описание можно добавить после `": "`, но это не обязательно.
|
||||
```sh
|
||||
opt_deps_arch=(
|
||||
'git: Управление репозиториями git'
|
||||
'aria2: Менеджер загрузок'
|
||||
)
|
||||
```
|
||||
|
||||
### replaces
|
||||
|
||||
Массив `replaces` содержит пакеты, которые заменяются данным пакетом. Обычно, если менеджеры пакетов находят пакет с установленным полем `replaces`, они удаляют указанные пакеты и устанавливают этот вместо них. Это полезно только в том случае, если пакеты хранятся в репозитории для вашего менеджера пакетов.
|
||||
|
||||
### sources
|
||||
|
||||
Массив `sources` содержит URL-адреса, которые загружаются в `$srcdir` перед началом сборки.
|
||||
|
||||
Если предоставленный URL является архивом или сжатым файлом, он будет извлечен. Чтобы отключить это, добавьте параметр `~archive=false`. Пример:
|
||||
Извлеченный:
|
||||
```sh
|
||||
https://example.com/archive.tar.gz
|
||||
```
|
||||
Не извлеченный:
|
||||
```sh
|
||||
https://example.com/archive.tar.gz?~archive=false
|
||||
```
|
||||
Если схема URL начинается с `git+`, источник будет загружен как git-репозиторий. Режим загрузки `git` поддерживает несколько параметров:
|
||||
|
||||
~rev: Укажите, какую ревизию репозитория нужно проверить.
|
||||
~depth: Укажите, какая глубина должна использоваться при клонировании репозитория. Должна быть целым числом.
|
||||
~name: Укажите имя директории, в которую должен быть клонирован git-репозиторий.
|
||||
~recursive: Если установлено в true, вложенные модули будут клонироваться рекурсивно. По умолчанию false.
|
||||
#tag=v${version}: Укажите тег, версия которого необходима из репозитория.
|
||||
|
||||
Примеры:
|
||||
```sh
|
||||
git+https://gitea.elara.ws/Elara6331/itd?~rev=resource-loading&~depth=1
|
||||
|
||||
git+https://gitea.elara.ws/alr/alr?~rev=v0.0.1&~recursive=true
|
||||
```
|
||||
|
||||
### checksums
|
||||
|
||||
Массив `checksums` должен быть такой же длины, как и массив [sources](#sources). Он содержит контрольные суммы для исходных файлов. Файлы проверяются на соответствие контрольным суммам, и сборка завершается неудачей, если они не совпадают.
|
||||
|
||||
По умолчанию ожидаются контрольные суммы в формате `sha256`. Чтобы изменить алгоритм, добавьте его перед хешем с двоеточием между ними. Например, `md5:bc0c6f5dcd06bddbca9a0163e4c9f2e1`. В настоящее время поддерживаются следующие алгоритмы: `sha256`, `sha224`, `sha512`, `sha384`, `sha1` и `md5`.
|
||||
|
||||
Чтобы пропустить проверку для определенного источника, установите соответствующую контрольную сумму в `SKIP`.
|
||||
|
||||
### backup
|
||||
|
||||
Массив `backup` содержит файлы, которые должны быть сохранены при обновлении и удалении. Точное поведение этого зависит от вашего менеджера пакетов. Все файлы в этом массиве должны быть полными путями назначения. Например, если существует конфигурационный файл под названием `config` в `/etc`, который вы хотите сохранить, вы должны установить его так:
|
||||
```sh
|
||||
backup=('/etc/config')
|
||||
```
|
||||
|
||||
### scripts
|
||||
|
||||
Переменная `scripts` содержит ассоциативный массив Bash, который указывает расположение различных скриптов относительно скрипта сборки. Пример:
|
||||
```sh
|
||||
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'
|
||||
)
|
||||
```
|
||||
Примечание: Для данного синтаксиса кавычки обязательны из-за ограничений парсера `bash`.
|
||||
|
||||
Скрипты `preupgrade` и `postupgrade` доступны только в пакетах `.apk` и *Arch Linux*.
|
||||
|
||||
Скрипты `pretrans` и `posttrans` доступны только в пакетах `.rpm`.
|
||||
|
||||
Остальные скрипты доступны во всех пакетах.
|
||||
|
||||
## Функции
|
||||
|
||||
В этом разделе описаны функции, определяемые пользователем, которые могут быть добавлены в скрипты сборки. Любые функции, отмеченные (*), являются обязательными.
|
||||
|
||||
Все функции выполняются в директории `$srcdir`.
|
||||
|
||||
### version()
|
||||
|
||||
Функция `version()` обновляет переменную `version`. Это позволяет автоматически извлекать версию из исходных файлов. Это наиболее полезно для git-пакетов, которые обычно не требуют изменений, поэтому их переменная `version` остается неизменной.
|
||||
|
||||
Пример использования для `git`:
|
||||
```sh
|
||||
version() {
|
||||
cd "$srcdir/itd"
|
||||
printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
|
||||
}
|
||||
```
|
||||
Аналогом в AUR является функция `pkgver()`.
|
||||
|
||||
### prepare()
|
||||
|
||||
Функция `prepare()` предназначена для подготовки исходных файлов к сборке и упаковке. Это функция, в которой должны применяться патчи, например, с помощью команды `patch`, и где должны выполняться инструменты, такие как `go generate`.
|
||||
|
||||
### build()
|
||||
|
||||
Функция `build()` — это место, где фактически происходит сборка пакета. Используйте те же команды, которые использовались бы для ручной компиляции программного обеспечения. Часто эта функция состоит всего из одной строки:
|
||||
```sh
|
||||
build() {
|
||||
make
|
||||
}
|
||||
```
|
||||
|
||||
### package()*
|
||||
|
||||
Функция `package()` — это место, куда помещаются собранные файлы в директорию, которая будет использоваться ALR для сборки пакета.
|
||||
|
||||
Все файлы, которые должны быть установлены в файловой системе, должны быть помещены в директорию `$pkgdir` в данной функции. Например, если у вас есть бинарный файл под названием `bin`, который должен быть помещен в `/usr/bin`, и конфигурационный файл под названием `bin.cfg`, который должен быть помещен в `/etc`, то функция `package()` может выглядеть так:
|
||||
```sh
|
||||
package() {
|
||||
install -Dm755 bin ${pkgdir}/usr/bin/bin
|
||||
install -Dm644 bin.cfg ${pkgdir}/etc/bin.cfg
|
||||
}
|
||||
```
|
||||
## Переменные окружения
|
||||
|
||||
ALR предоставляет несколько значений в виде переменных окружения для использования в скриптах сборки.
|
||||
|
||||
### DISTRO_NAME
|
||||
|
||||
Переменная `DISTRO_NAME` — это имя дистрибутива, определенное в его файле `os-release`.
|
||||
|
||||
Например, в образе *Docker Fedora 36* оно установлено в `Fedora Linux`.
|
||||
|
||||
### DISTRO_PRETTY_NAME
|
||||
|
||||
Переменная `DISTRO_PRETTY_NAME` — это "красивое" имя дистрибутива, определенное в его файле `os-release`.
|
||||
|
||||
Например, в образе *Docker Fedora 36* оно установлено в `Fedora Linux 36 (Container Image)`.
|
||||
|
||||
### DISTRO_ID
|
||||
|
||||
Переменная `DISTRO_ID` — это идентификатор дистрибутива, определенный в его файле `os-release`. Это то же самое, что и то, что ALR использует для переопределений.
|
||||
|
||||
Например, в образе *Docker Fedora 36* оно установлено в `fedora`.
|
||||
|
||||
### DISTRO_ID_LIKE
|
||||
|
||||
Переменная `DISTRO_ID_LIKE` содержит идентификаторы похожих дистрибутивов для текущего, разделенные пробелами.
|
||||
|
||||
Например, в образе *Docker OpenSUSE Tumbleweed* она установлена в `opensuse suse`, а в образе *Docker CentOS 8* — в `rhel fedora`.
|
||||
|
||||
### DISTRO_VERSION_ID
|
||||
|
||||
Переменная `DISTRO_VERSION_ID` — это идентификатор версии дистрибутива, определенный в его файле `os-release`.
|
||||
|
||||
Например, в образе *Docker Fedora 36* она установлена в `36`, а в образе *Docker Debian Bullseye* — в `11`.
|
||||
|
||||
### ARCH
|
||||
|
||||
Переменная `ARCH` — это архитектура машины, на которой выполняется скрипт. Она использует ту же схему именования, что и значения в массиве `architectures`.
|
||||
|
||||
### NCPU
|
||||
|
||||
Переменная `NCPU` — это количество доступных на машине процессоров, на которой выполняется скрипт. Например, на четырёхъядерной машине с гипертредингом оно будет установлено в `8`.
|
||||
|
||||
## Вспомогательные команды
|
||||
|
||||
ALR предоставляет различные команды, чтобы помочь мейнтейнерам создавать правильные кросс-дистрибутивные пакеты. Эти команды должны использоваться, где это возможно, вместо выполнения задач вручную.
|
||||
|
||||
### install-binary
|
||||
|
||||
`install-binary` принимает 1-2 аргумента. Первый аргумент — это бинарный файл, который вы хотите установить. Второй — это имя файла, которое должно быть использовано.
|
||||
|
||||
Если аргумент имени файла не предоставлен, будет использовано имя входного файла.
|
||||
|
||||
Примеры:
|
||||
```sh
|
||||
install-binary ./itd
|
||||
install-binary ./itd itd-2
|
||||
```
|
||||
|
||||
### install-systemd
|
||||
|
||||
`install-systemd` устанавливает обычные системные службы *systemd* (см. [install-systemd-user](#install-systemd-user) для пользовательских служб).
|
||||
|
||||
Он принимает 1-2 аргумента. Первый аргумент — это служба, которую вы хотите установить. Второй — это имя файла, которое должно быть использовано.
|
||||
|
||||
Если аргумент имени файла не предоставлен, будет использовано имя входного файла.
|
||||
|
||||
Примеры:
|
||||
```sh
|
||||
install-systemd ./syncthing@.service
|
||||
```
|
||||
|
||||
### install-systemd-user
|
||||
|
||||
`install-systemd-user` устанавливает пользовательские службы systemd (службы, предназначенные для запуска с флагом `--user`).
|
||||
|
||||
Он принимает 1-2 аргумента. Первый аргумент — это служба, которую вы хотите установить. Второй — это имя файла, которое должно быть использовано.
|
||||
|
||||
Если аргумент имени файла не предоставлен, будет использовано имя входного файла.
|
||||
|
||||
Примеры:
|
||||
```sh
|
||||
install-systemd-user ./itd.service infinitime-daemon.service
|
||||
```
|
||||
|
||||
### install-config
|
||||
|
||||
`install-config` устанавливает конфигурационные файлы в директорию `/etc`.
|
||||
|
||||
Он принимает 1-2 аргумента. Первый аргумент — это конфигурация, которую вы хотите установить. Второй — это имя файла, которое должно быть использовано.
|
||||
|
||||
Если аргумент имени файла не предоставлен, будет использовано имя входного файла.
|
||||
|
||||
Примеры:
|
||||
```sh
|
||||
install-config ./itd.toml
|
||||
install-config ./itd.example.toml itd.toml
|
||||
```
|
||||
|
||||
### install-license
|
||||
|
||||
`install-license` устанавливает файл лицензии.
|
||||
|
||||
Он принимает 1-2 аргумента. Первый аргумент — это конфигурация, которую вы хотите установить. Второй — это имя файла, которое должно быть использовано.
|
||||
|
||||
Если аргумент имени файла не предоставлен, будет использовано имя входного файла.
|
||||
|
||||
Примеры:
|
||||
```sh
|
||||
install-license ./LICENSE itd/LICENSE
|
||||
```
|
||||
|
||||
### install-completion
|
||||
|
||||
`install-completion` устанавливает файлы для автозавершения для командной строки.
|
||||
|
||||
В настоящее время поддерживаются `bash`, `zsh` и `fish`.
|
||||
|
||||
Завершения читаются из стандартного ввода, их можно либо передать через конвейер, либо получить из файлов.
|
||||
|
||||
Для этой функции требуются два аргумента. Первый — это имя оболочки, второй — это имя завершения.
|
||||
|
||||
Примеры:
|
||||
```sh
|
||||
./k9s completion fish | install-completion fish k9s
|
||||
install-completion bash k9s <./k9s/completions/k9s.bash
|
||||
```
|
||||
|
||||
### install-manual
|
||||
|
||||
`install-manual` устанавливает страницы `man`. Она принимает один аргумент, который является путем к странице `man`.
|
||||
|
||||
Путь установки будет определен на основе номера в конце имени файла. Если номер не может быть извлечен, будет возвращена ошибка.
|
||||
|
||||
Примеры:
|
||||
```sh
|
||||
install-manual ./man/strelaysrv.1
|
||||
install-manual ./mdoc.7
|
||||
```
|
||||
|
||||
### install-desktop
|
||||
|
||||
`install-desktop` устанавливает desktop-файлы для приложений. Он принимает 1-2 аргумента. Первый аргумент — это конфигурация, которую вы хотите установить. Второй — это имя файла, которое должно быть использовано.
|
||||
|
||||
Если аргумент имени файла не предоставлен, будет использовано имя входного файла.
|
||||
|
||||
Примеры:
|
||||
```sh
|
||||
install-desktop ./${name}/share/admc.desktop
|
||||
install-desktop ./${name}/share/admc.desktop admc-app.desktop
|
||||
```
|
||||
|
||||
### install-library
|
||||
|
||||
`install-library` устанавливает общие и статические библиотеки в правильное место.
|
||||
|
||||
Это самая важная вспомогательная функция, так как она содержит логику, чтобы определить, куда установить библиотеки в зависимости от целевого дистрибутива и архитектуры `CPU`. Она почти всегда должна использоваться для установки всех библиотек.
|
||||
|
||||
Он принимает 1-2 аргумента. Первый аргумент — это конфигурация, которую вы хотите установить. Второй — это имя файла, которое должно быть использовано.
|
||||
|
||||
Если аргумент имени файла не предоставлен, будет использовано имя входного файла.
|
||||
|
||||
Примеры:
|
||||
```sh
|
||||
install-library ./${name}/build/libadldap.so
|
||||
```
|
||||
|
||||
### git-version
|
||||
|
||||
`git-version` возвращает номер версии на основе git-ревизии репозитория.
|
||||
|
||||
Если аргумент предоставлен, он будет использован как путь к репозиторию. В противном случае будет использован текущий каталог.
|
||||
|
||||
Номер версии будет содержать количество ревизий, точку и короткий хеш текущей ревизии. Например: `118.e4b8348`.
|
||||
|
||||
Конвенция AUR включает букву `r` в начале номера версии. Это опускается, так как некоторые дистрибутивы ожидают, что номер версии начнется с цифры.
|
||||
|
||||
Примеры:
|
||||
```sh
|
||||
git-version
|
||||
git-version "$srcdir/alr"
|
||||
```
|
||||
@ -1,12 +1,10 @@
|
||||
# Configuration
|
||||
|
||||
На этой странице описана конфигурация ALR
|
||||
# Конфигурация
|
||||
|
||||
---
|
||||
|
||||
## Оглавление
|
||||
|
||||
- [Конфигурационный файл](#config-file)
|
||||
- [Расположение файлов](#расположение-файлов)
|
||||
- [Конфигурационный файл](#Конфигурационный-файл)
|
||||
- [rootCmd](#rootcmd)
|
||||
- [repo](#repo)
|
||||
|
||||
|
||||
31
conventions.md
Normal file
31
conventions.md
Normal file
@ -0,0 +1,31 @@
|
||||
# Общие рекомендации
|
||||
|
||||
Пакеты должны содержать название(я) того, что они содержат, в массивах `provides` и `conflicts`. Таким образом, пользователи могут устанавливать их, не зная полного названия пакета. Например, существуют два пакета `admc` для ADMC: admc и admc-git. Оба из них имеют массивы `provides` и `conflicts`, указывающие на две команды, которые они устанавливают. Это означает, что если пользователь хочет установить *ADMC*, ему просто нужно ввести `alr in admc`, и ALR предложит ему выбрать, какой из них он хочет установить.
|
||||
|
||||
## Бинарные пакеты
|
||||
|
||||
Пакеты, которые устанавливают загруженные и установленные предварительно скомпилированные бинарные файлы, должны иметь суффикс `-bin`.
|
||||
|
||||
## Пакеты Git
|
||||
|
||||
Пакеты, которые собирают и устанавливают программы из исходного кода, клонируемого непосредственно из Git, должны иметь суффикс `-git`.
|
||||
|
||||
Версии этих пакетов должны состоять из количества ревизий, за которым следует текущая ревизия, разделенные точкой. Например: `183.80187b0`. Обратите внимание, что в отличие от *AUR*, в начале нет `r`. Это связано с тем, что некоторые менеджеры пакетов отказываются устанавливать пакеты, номера версий которых не начинаются с цифры.
|
||||
|
||||
Этот номер версии можно получить с помощью следующей команды:
|
||||
```sh
|
||||
printf "%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
|
||||
```
|
||||
|
||||
Функция [version()](build-scripts.md#version) для таких пакетов должна использовать предоставленную ALR функцию [git-version](build-scripts.md#git-version), следующим образом:
|
||||
|
||||
```sh
|
||||
version() {
|
||||
cd "$srcdir/$name"
|
||||
git-version
|
||||
}
|
||||
```
|
||||
Это использует встроенную реализацию Git от alr, что гарантирует, что пользователю не нужно устанавливать Git на свою систему для установки пакетов `-git`.
|
||||
## Прочие пакеты
|
||||
|
||||
Пакеты, которые загружают исходники для конкретной версии программы, не должны иметь никаких суффиксов, даже если эти исходники загружаются из Git.
|
||||
@ -1,5 +0,0 @@
|
||||
# LURE Docs > Packages
|
||||
|
||||
- [Build Scripts](build-scripts.md)
|
||||
- [Package Conventions](conventions.md)
|
||||
- [Adding Packages to LURE's repo](adding-packages.md)
|
||||
@ -1,19 +0,0 @@
|
||||
# Добавление пакетов для репозитория 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 откроет измененный репозиторий, и ваш пакет будет доступен для установки пользователям.
|
||||
@ -1,499 +0,0 @@
|
||||
# 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"
|
||||
```
|
||||
@ -1,36 +0,0 @@
|
||||
# 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.
|
||||
226
usage.md
226
usage.md
@ -1,205 +1,177 @@
|
||||
# Использование
|
||||
|
||||
## Оглавление
|
||||
|
||||
- [Команды](#команды)
|
||||
- [Установка](#install)
|
||||
- [Удаление](#remove)
|
||||
- [Обновление пакетов](#upgrade)
|
||||
- [Информация](#info)
|
||||
- [Список](#list)
|
||||
- [Сборка](#build)
|
||||
- [ДОбавление репозитория](#addrepo)
|
||||
- [Удаление репозитория](#removerepo)
|
||||
- [Обновление изменений](#refresh)
|
||||
- [Исправление](#fix)
|
||||
- [Версия](#version)
|
||||
- [Переменные окружения](#environment-variables)
|
||||
- [Дистрибутивы](#alr_distro)
|
||||
- [Формат пакета](#alr_pkg_format)
|
||||
- [Архитектура](#alr_arm_variant)
|
||||
|
||||
---
|
||||
|
||||
- [Команды](#команды)
|
||||
- [Установка](#install)
|
||||
- [Удаление](#remove)
|
||||
- [Обновление пакетов](#upgrade)
|
||||
- [Информация о пакете](#info)
|
||||
- [Список пакетов](#list)
|
||||
- [Сборка](#build)
|
||||
- [Добавление репозитория](#addrepo)
|
||||
- [Удаление репозитория](#removerepo)
|
||||
- [Обновление изменений](#)
|
||||
- [Исправление](#)
|
||||
- [Версия](#)
|
||||
- [Переменные окружения](#)
|
||||
- [Дистрибутивы](#)
|
||||
- [Формат пакета](#)
|
||||
- [Архитектура](#)
|
||||
|
||||
## команды
|
||||
|
||||
Аргумент имени пакета не обязан быть точными(для пакетов из репозитория ALR).
|
||||
|
||||
### install
|
||||
|
||||
Команда установки устанавливает пакет из репозиториев Alr. Любые пакеты, которых нет в репозиториях Alr, передаются в системный менеджер пакетов для установки.
|
||||
Аргументы пакета не обязаны быть точными. Alr проверит массив и сообщит, если точное совпадение не найдено. Также поддерживается использование "%" в качестве замены.
|
||||
Если найдено несколько пакетов, вы будете проинформированы о выборе пакета для установки.
|
||||
По умолчанию, если пакет уже был собран, Alr установит кэшированный пакет вместо пересобирания. Используйте флаг -c или --clean, чтобы принудительно пересобрать пакет.
|
||||
Команда `install` устанавливает пакет из репозиториев ALR. Любые пакеты, которых нет в репозиториях ALR, передаются в системный менеджер пакетов для установки. ALR проверит массив и сообщит, если точное совпадение не найдено. Также поддерживается использование `%` в качестве замены. Если найдено несколько пакетов, вы будете проинформированы о выборе пакета для установки. По умолчанию, если пакет уже был собран, ALR установит кэшированный пакет вместо повторной пересборки. Используйте флаг `-c` или `--clean`, чтобы принудительно пересобрать пакет.
|
||||
|
||||
Примеры:
|
||||
```shell
|
||||
```sh
|
||||
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 alr # находит alr-bin и alr-git
|
||||
alr in it% # находит alr-bin, alr-git и 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.
|
||||
Команда `remove` предназначена для удобства. Она просто перенаправляет команду удаления в системный менеджер пакетов.
|
||||
|
||||
Example:
|
||||
|
||||
```shell
|
||||
Пример:
|
||||
```sh
|
||||
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.
|
||||
Команда `upgrade` просматривает установленные в вашей системе пакеты и проверяет, соответствуют ли они пакетам из репозиториев ALR. Если да, то их версии сравниваются с использованием алгоритма `rpmvercmp`. Если в репозиториях ALR содержится более новая версия, пакет обновляется.
|
||||
|
||||
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.
|
||||
По умолчанию, если пакет уже был собран, ALR установит кэшированный пакет, а не пересоберёт его. Используйте флаг `-c` или `--clean`, чтобы принудительно пересобрать.
|
||||
|
||||
Example:
|
||||
|
||||
```shell
|
||||
Пример:
|
||||
```sh
|
||||
alr up
|
||||
```
|
||||
|
||||
### info
|
||||
|
||||
The info command displays information about a package in alr's repos.
|
||||
Команда `info` отображает информацию о пакете в репозиториях ALR.
|
||||
|
||||
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
|
||||
Пример:
|
||||
```sh
|
||||
alr info alr-bin # находит только alr-bin
|
||||
alr info alr # находит alr-bin и alr-git
|
||||
alr info it% # находит alr-bin, alr-git и itgui-git
|
||||
```
|
||||
|
||||
### list
|
||||
|
||||
The list command lists all alr repo packages as well as their versions
|
||||
Команда `list` отображает все пакеты из репозитория ALR, а также их версии.
|
||||
|
||||
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.
|
||||
Существует флаг `-I` или `--installed`, который фильтрует пакеты, установленные в системе.
|
||||
|
||||
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"
|
||||
Примеры:
|
||||
```sh
|
||||
alr ls # выводит все пакеты alr
|
||||
alr ls -I # выводит все установленные пакеты
|
||||
alr ls i% # выводит все пакеты, начинающиеся с "i"
|
||||
alr ls %d # выводит все пакеты, заканчивающиеся на "d"
|
||||
alr ls -I i% # выводит все установленные пакеты, начинающиеся с "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.
|
||||
Команда `build` собирает пакет с использованием скрипта сборки `alr.sh` в текущем каталоге. Путь к скрипту можно изменить с помощью флага `-s`.
|
||||
|
||||
Example:
|
||||
|
||||
```shell
|
||||
Пример:
|
||||
```sh
|
||||
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.
|
||||
Команда `addrepo` добавляет репозиторий в ALR, если он еще не существует. Флаг `-n` устанавливает имя репозитория, а флаг `-u` — это URL репозитория. Оба являются обязательными.
|
||||
|
||||
Example:
|
||||
|
||||
```shell
|
||||
alr ar -n default -u https://github.com/Elara6331/alr-repo
|
||||
Пример:
|
||||
```sh
|
||||
alr ar -n default -u https://gitea.plemya-x.ru/xpamych/xpamych-alr-repo.git
|
||||
```
|
||||
|
||||
### 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.
|
||||
Команда `removerepo` удаляет репозиторий из ALR и удаляет его содержимое, если он существует. Флаг `-n` указывает имя репозитория, который необходимо удалить.
|
||||
|
||||
Example:
|
||||
|
||||
```shell
|
||||
Пример:
|
||||
```sh
|
||||
alr rr -n default
|
||||
```
|
||||
|
||||
### refresh
|
||||
|
||||
The refresh command pulls all changes from all alr repos that have changed.
|
||||
Команда `refresh` загружает все изменения из всех репозиториев ALR, которые были изменены.
|
||||
|
||||
Example:
|
||||
|
||||
```shell
|
||||
Пример:
|
||||
```sh
|
||||
alr ref
|
||||
```
|
||||
|
||||
### fix
|
||||
|
||||
The fix command attempts to fix issues with alr by deleting and rebuilding alr's cache
|
||||
Команда `fix` пытается исправить проблемы с ALR, удаляя и пересобирая кэш ALR.
|
||||
|
||||
Example:
|
||||
|
||||
```shell
|
||||
Пример:
|
||||
```sh
|
||||
alr fix
|
||||
```
|
||||
|
||||
### version
|
||||
|
||||
The version command returns the current alr version and exits
|
||||
Команда version возвращает текущую версию ALR и завершает выполнение.
|
||||
|
||||
Example:
|
||||
|
||||
```shell
|
||||
Пример:
|
||||
```sh
|
||||
alr version
|
||||
```
|
||||
## Переменные окружения
|
||||
### ALR_DISTRO
|
||||
|
||||
---
|
||||
|
||||
## 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` должна быть установлена в дистрибутив, для которого должен быть собран пакет. Это говорит ALR, какие переопределения использовать. Значения должны совпадать с полем `ID` в `/etc/os-release` или `/usr/lib/os-release`. Возможные значения включают:
|
||||
```sh
|
||||
arch
|
||||
alpine
|
||||
opensuse
|
||||
debian
|
||||
```
|
||||
|
||||
### ALR_PKG_FORMAT
|
||||
|
||||
Переменная окружения `ALR_PKG_FORMAT` должна быть установлена в формат упаковки, который следует использовать. Допустимые значения:
|
||||
```
|
||||
archlinux
|
||||
apk
|
||||
rpm
|
||||
deb
|
||||
```
|
||||
### ALR_ARM_VARIANT
|
||||
|
||||
Переменная окружения `ALR_ARM_VARIANT` указывает, для какого варианта ARM следует собирать, если ALR работает на ARM-системе. Возможные значения включают:
|
||||
```
|
||||
arm5
|
||||
arm6
|
||||
arm7
|
||||
```
|
||||
## Кросс-упаковка для других дистрибутивов
|
||||
|
||||
Вы можете создавать пакеты для различных дистрибутивов, устанавливая переменные окружения `ALR_DISTRO` и `ALR_PKG_FORMAT`, как указано выше.
|
||||
|
||||
Примеры:
|
||||
```sh
|
||||
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
|
||||
```
|
||||
|
||||
---
|
||||
```
|
||||
Loading…
Reference in New Issue
Block a user