29 KiB
ALR скрипт сборки
ALR использует скрипты сборки, похожие на PKGBUILD
's AUR. Ниже описаны требования к содержимому.
Переопределение дистрибутива
Использование ALR в различных дистрибутивах представляет собой некоторые проблемы. Например, некоторые дистрибутивы используют разные названия для своих пакетов. Это решается с помощью переопределений дистрибутива. Любая переменная или функция, используемая в скрипте сборки ALR, может быть переопределена в зависимости от дистрибутива и архитектуры CPU. Сделать это можно, добавляя наименование дистрибутива и/или архитектуры в конец имени. Например, ALR зависит от пакета go
. Go
имеет несколько разные названия на различных дистрибутивах. Для ALR я использую следующее для зависимостей:
deps=('golang')
deps_arch=('go' )
deps_opensuse=('go')
Добавление arch
и opensuse
в конец заставляет ALR использовать соответствующий массив в зависимости от дистрибутива. Если вы находитесь на Arch Linux, он будет использовать deps_arch
. Если на OpenSUSE, он будет использовать deps_opensuse
, а если на что-то другое, то будет использовать deps
.
Имена проверяются в следующем порядке:
$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
содержит имя и адрес электронной почты человека, поддерживающего пакет. Пример:
Евгений Храмов <xpamych@yandex.ru>
Хотя ALR не требует установки этого поля, Debian отказался от неустановленных полей maintainer
и может запретить их использование в пакетах .deb в будущем.
architectures
Массив architectures
содержит все архитектуры, которые поддерживает данный пакет. Они соответствуют списку GOARCH
языка Go
, за исключением некоторых отличий.
Архитектура all
будет переведена на правильный термин для формата упаковки. Например, он будет изменен на noarch
, если строится .rpm
, или any
, если строится пакет Arch.
Поскольку существует несколько вариантов архитектуры arm
, должны использоваться следующие значения:
arm5: armv5
arm6: armv6
arm7: armv7
ALR попытается определить, какой вариант использует ваша система, проверяя существование различных функций CPU
. Если это дает неправильный результат или если вы просто хотите собрать для другого варианта, переменная alr_ARM_VARIANT
должна быть установлена в желаемый вариант ARM
. Пример:
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
содержит необязательные зависимости для пакета. Описание можно добавить после ": "
, но это не обязательно.
opt_deps_arch=(
'git: Управление репозиториями git'
'aria2: Менеджер загрузок'
)
replaces
Массив replaces
содержит пакеты, которые заменяются данным пакетом. Обычно, если менеджеры пакетов находят пакет с установленным полем replaces
, они удаляют указанные пакеты и устанавливают этот вместо них. Это полезно только в том случае, если пакеты хранятся в репозитории для вашего менеджера пакетов.
sources
Массив sources
содержит URL-адреса, которые загружаются в $srcdir
перед началом сборки.
Если предоставленный URL является архивом или сжатым файлом, он будет извлечен. Чтобы отключить это, добавьте параметр ~archive=false
. Пример:
Извлеченный:
https://example.com/archive.tar.gz
Не извлеченный:
https://example.com/archive.tar.gz?~archive=false
Если схема URL начинается с git+
, источник будет загружен как git-репозиторий. Режим загрузки git
поддерживает несколько параметров:
~rev: Укажите, какую ревизию репозитория нужно проверить.
~depth: Укажите, какая глубина должна использоваться при клонировании репозитория. Должна быть целым числом.
~name: Укажите имя директории, в которую должен быть клонирован git-репозиторий.
~recursive: Если установлено в true, вложенные модули будут клонироваться рекурсивно. По умолчанию false.
#tag=v${version}: Укажите тег, версия которого необходима из репозитория.
Примеры:
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. Он содержит контрольные суммы для исходных файлов. Файлы проверяются на соответствие контрольным суммам, и сборка завершается неудачей, если они не совпадают.
По умолчанию ожидаются контрольные суммы в формате sha256
. Чтобы изменить алгоритм, добавьте его перед хешем с двоеточием между ними. Например, md5:bc0c6f5dcd06bddbca9a0163e4c9f2e1
. В настоящее время поддерживаются следующие алгоритмы: sha256
, sha224
, sha512
, sha384
, sha1
и md5
.
Чтобы пропустить проверку для определенного источника, установите соответствующую контрольную сумму в SKIP
.
backup
Массив backup
содержит файлы, которые должны быть сохранены при обновлении и удалении. Точное поведение этого зависит от вашего менеджера пакетов. Все файлы в этом массиве должны быть полными путями назначения. Например, если существует конфигурационный файл под названием config
в /etc
, который вы хотите сохранить, вы должны установить его так:
backup=('/etc/config')
scripts
Переменная scripts
содержит ассоциативный массив 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'
)
Примечание: Для данного синтаксиса кавычки обязательны из-за ограничений парсера bash
.
Скрипты preupgrade
и postupgrade
доступны только в пакетах .apk
и Arch Linux.
Скрипты pretrans
и posttrans
доступны только в пакетах .rpm
.
Остальные скрипты доступны во всех пакетах.
Функции
В этом разделе описаны функции, определяемые пользователем, которые могут быть добавлены в скрипты сборки. Любые функции, отмеченные (*), являются обязательными.
Все функции выполняются в директории $srcdir
.
version()
Функция version()
обновляет переменную version
. Это позволяет автоматически извлекать версию из исходных файлов. Это наиболее полезно для git-пакетов, которые обычно не требуют изменений, поэтому их переменная version
остается неизменной.
Пример использования для git
:
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()
— это место, где фактически происходит сборка пакета. Используйте те же команды, которые использовались бы для ручной компиляции программного обеспечения. Часто эта функция состоит всего из одной строки:
build() {
make
}
package()*
Функция package()
— это место, куда помещаются собранные файлы в директорию, которая будет использоваться ALR для сборки пакета.
Все файлы, которые должны быть установлены в файловой системе, должны быть помещены в директорию $pkgdir
в данной функции. Например, если у вас есть бинарный файл под названием bin
, который должен быть помещен в /usr/bin
, и конфигурационный файл под названием bin.cfg
, который должен быть помещен в /etc
, то функция package()
может выглядеть так:
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 аргумента. Первый аргумент — это бинарный файл, который вы хотите установить. Второй — это имя файла, которое должно быть использовано.
Если аргумент имени файла не предоставлен, будет использовано имя входного файла.
Примеры:
install-binary ./itd
install-binary ./itd itd-2
install-systemd
install-systemd
устанавливает обычные системные службы systemd (см. install-systemd-user для пользовательских служб).
Он принимает 1-2 аргумента. Первый аргумент — это служба, которую вы хотите установить. Второй — это имя файла, которое должно быть использовано.
Если аргумент имени файла не предоставлен, будет использовано имя входного файла.
Примеры:
install-systemd ./syncthing@.service
install-systemd-user
install-systemd-user
устанавливает пользовательские службы systemd (службы, предназначенные для запуска с флагом --user
).
Он принимает 1-2 аргумента. Первый аргумент — это служба, которую вы хотите установить. Второй — это имя файла, которое должно быть использовано.
Если аргумент имени файла не предоставлен, будет использовано имя входного файла.
Примеры:
install-systemd-user ./itd.service infinitime-daemon.service
install-config
install-config
устанавливает конфигурационные файлы в директорию /etc
.
Он принимает 1-2 аргумента. Первый аргумент — это конфигурация, которую вы хотите установить. Второй — это имя файла, которое должно быть использовано.
Если аргумент имени файла не предоставлен, будет использовано имя входного файла.
Примеры:
install-config ./itd.toml
install-config ./itd.example.toml itd.toml
install-license
install-license
устанавливает файл лицензии.
Он принимает 1-2 аргумента. Первый аргумент — это конфигурация, которую вы хотите установить. Второй — это имя файла, которое должно быть использовано.
Если аргумент имени файла не предоставлен, будет использовано имя входного файла.
Примеры:
install-license ./LICENSE itd/LICENSE
install-completion
install-completion
устанавливает файлы для автозавершения для командной строки.
В настоящее время поддерживаются bash
, zsh
и fish
.
Завершения читаются из стандартного ввода, их можно либо передать через конвейер, либо получить из файлов.
Для этой функции требуются два аргумента. Первый — это имя оболочки, второй — это имя завершения.
Примеры:
./k9s completion fish | install-completion fish k9s
install-completion bash k9s <./k9s/completions/k9s.bash
install-manual
install-manual
устанавливает страницы man
. Она принимает один аргумент, который является путем к странице man
.
Путь установки будет определен на основе номера в конце имени файла. Если номер не может быть извлечен, будет возвращена ошибка.
Примеры:
install-manual ./man/strelaysrv.1
install-manual ./mdoc.7
install-desktop
install-desktop
устанавливает desktop-файлы для приложений. Он принимает 1-2 аргумента. Первый аргумент — это конфигурация, которую вы хотите установить. Второй — это имя файла, которое должно быть использовано.
Если аргумент имени файла не предоставлен, будет использовано имя входного файла.
Примеры:
install-desktop ./${name}/share/admc.desktop
install-desktop ./${name}/share/admc.desktop admc-app.desktop
install-library
install-library
устанавливает общие и статические библиотеки в правильное место.
Это самая важная вспомогательная функция, так как она содержит логику, чтобы определить, куда установить библиотеки в зависимости от целевого дистрибутива и архитектуры CPU
. Она почти всегда должна использоваться для установки всех библиотек.
Он принимает 1-2 аргумента. Первый аргумент — это конфигурация, которую вы хотите установить. Второй — это имя файла, которое должно быть использовано.
Если аргумент имени файла не предоставлен, будет использовано имя входного файла.
Примеры:
install-library ./${name}/build/libadldap.so
git-version
git-version
возвращает номер версии на основе git-ревизии репозитория.
Если аргумент предоставлен, он будет использован как путь к репозиторию. В противном случае будет использован текущий каталог.
Номер версии будет содержать количество ревизий, точку и короткий хеш текущей ревизии. Например: 118.e4b8348
.
Конвенция AUR включает букву r
в начале номера версии. Это опускается, так как некоторые дистрибутивы ожидают, что номер версии начнется с цифры.
Примеры:
git-version
git-version "$srcdir/alr"