PKGBUILD (Русский)
В статье рассмотрены определяемые сопроводителем пакета переменные файла PKGBUILD
. Если вы ищете информацию об используемых в PKGBUILD
функциях или о создании пакетов в целом, изучите статью Создание пакетов. Также стоит прочитать руководство PKGBUILD(5).
PKGBUILD
— сценарий оболочки, содержащий информацию, необходимую для сборки пакета Arch Linux.
В Arch Linux пакеты собираются утилитой makepkg. При запуске makepkg находит в рабочем каталоге файл PKGBUILD
и выполняет содержащиеся в нём указания по получению необходимых файлов, их компиляции и сборке архива пакета название_пакета.pkg.tar.zst
. Итоговый пакет состоит из двоичных файлов и инструкций по установке; с помощью pacman его можно установить в систему.
Обязательными являются переменные pkgname
, pkgver
, pkgrel
и arch
. Параметр license
можно не указывать, но в этом случае makepkg выдаст предупреждение. Если вы планируете распространять PKGBUILD
среди других пользователей, лучше его всё-таки добавить.
Как правило, переменные в файле PKGBUILD
объявляются в том порядке, в каком перечислены здесь, но требованием это не является. Главное — соблюдать синтаксис Bash.
PKGBUILD
на предмет распространённых ошибок.Название пакета
pkgbase
При сборке обычных пакетов эту переменную указывать не нужно: она по умолчанию принимает значение #pkgname.
При сборке разделённого пакета в ней указывают значение, которым обозначается данная группа пакетов и которое используется в имени tar-архива с исходниками. Значение не должно начинаться с дефиса. Если никакое значение не указано, то берётся первый элемент массива pkgname
.
Все параметры и указания для разделённых пакетов по умолчанию используют глобальные значения из PKGBUILD
. Тем не менее, следующие параметры могут быть переопределены в функциях упаковки каждого из разделённых пакетов: #pkgdesc, #arch, #url, #license, #groups, #depends, #optdepends, #provides, #conflicts, #replaces, #backup, #options, #install и #changelog.
pkgname
Либо название пакета (например, pkgname='foo'
), либо, в случае разделённых пакетов, массив названий (например, pkgname=('foo' 'bar')
). Название пакета должно состоять из латинских букв в нижнем регистре, цифр и символов @._+-
("собака", точка, подчёркивание, плюс, дефис). Название не может начинаться с дефиса или точки. Для удобства принято за правило, что pkgname
должен совпадать с названием tar-архива исходников программы. Так, если код программы упакован в архив foobar-2.5.tar.gz
, то используйте pkgname=foobar
.
Версия
pkgver
Версия пакета. Должна совпадать с номером версии, который используется автором программы в апстриме. Состоит из букв, чисел, точек и подчёркиваний, но дефис использовать нельзя. Если автор программы использовал в номере версии дефис, замените его на символ подчёркивания. При дальнейшем использовании этой переменной в PKGBUILD
подчёркивание можно легко изменить обратно на дефис, например: source=("$pkgname-${pkgver//_/-}.tar.gz")
.
30102014
, используйте "перевёрнутую" дату (20141030
, формат ISO 8601). В противном случае пакет не будет отображаться как новейшая версия.
- Относительный порядок для нестандартных значений можно протестировать утилитой vercmp(8) из пакета pacman.
- makepkg может автоматически обновлять значение данной переменной с помощью функции
pkgver()
файлаPKGBUILD
. Подробнее см. VCS package guidelines#The pkgver() function.
pkgrel
Номер релиза. Обычно положительное целое число. Позволяет различать последовательные сборки одной и той же версии пакета. Каждый раз, когда в PKGBUILD
вносятся исправления или дополнения, влияющие на итоговый пакет, значение этой переменной необходимо увеличить на 1. Когда выходит новая версия программы, pkgrel
сбрасывается до значения 1. В исключительных случаях могут использоваться некоторые другие форматы, вроде старший.младший.
epoch
epoch
должна использоваться исключительно в тех случаях, когда без неё действительно не обойтись.Позволяет сделать версию пакета более новой по отношению ко всем предыдущим версиям более низких "эпох". Может принимать неотрицательные значения; по умолчанию равна 0. Применяется в случаях, когда изменилась схема нумерации версий пакета (или используется буквенно-цифровая нумерация), что ломает обычную логику сравнения версий. Пример:
pkgver=5.13 pkgrel=2 epoch=1
1:5.13-2
О сравнении версий см. pacman(8).
Общие
pkgdesc
Описание пакета. Рекомендованная длина — не более 80 символов. Описание не должно содержать названия самого пакета в явном виде, за исключением случаев, когда название приложения от него отличается. Например, вместо pkgdesc="Nedit is a text editor for X11"
("Nedit — текстовый редактор для X11") лучше указать просто pkgdesc="Text editor for X11"
("Текстовый редактор для X11").
Также не забывайте использовать в описании пакета ключевые слова, чтобы его было проще найти с помощью поиска.
arch
Массив названий архитектур, под которые пакет может быть собран по данному PKGBUILD
. Arch официально поддерживает только x86_64
, но существуют сторонние проекты для других архитектур. Например, Arch Linux 32 работает с i686
и pentium4
, а Arch Linux ARM предоставляет поддержку для arm
(armv5), armv6h
(armv6 hardfloat), armv7h
(armv7 hardfloat) и aarch64
(armv8 64-bit).
В параметре используются два типа значений:
arch=('any')
— пакет соберётся на любой архитектуре и в откомпилированном состоянии будет архитектурно-независимым (пакеты со сценариями оболочки, шрифтами, темами, многими типами расширений и т.п.).arch=('x86_64')
— пакет соберётся только на указанной(-ых) архитектуре(-ах). После компиляции пакет становится архитектурно-зависимым. В параметре указываются все архитектуры, для которых будет работать данныйPKGBUILD
. Для пакетов из официальных репозиториев и AUR в параметреarch
указывается значение x86_64, хотя пакеты из AUR могут также поддерживать дополнительные архитектуры.
В процессе сборки значение целевой архитектуры хранится в переменной $CARCH
.
url
Адрес официального сайта той программы, которая собирается в пакет.
license
Лицензия, под которой распространяется программа. В пакете licenses (зависимость мета-пакета base) собраны наиболее распространённые лицензии; при установке они размещаются в каталоге /usr/share/licenses/common/
. Если программа распространяется под одной из этих лицензий, то в параметре необходимо указать значение, совпадающее с названием соответствующего подкаталога (например, license=('GPL')
). Если используется лицензия, отсутствующая в licenses, необходимо сделать следующее:
- Укажите в параметре
license
значениеcustom
(либоcustom:лицензия
). Когда некая лицензия используется в двух или более пакетах из официальных репозиториев, её добавляют в пакет licenses. - Скопируйте файл лицензии в каталог
/usr/share/licenses/пакет/
, например,/usr/share/licenses/foobar/LICENSE
. Проще всего это сделать командойinstall -Dm644 LICENSE "$pkgdir/usr/share/licenses/$pkgname/LICENSE"
- Если лицензию можно найти только на веб-сайте, то её придётся включить в пакет отдельно.
- Лицензии BSD, ISC, MIT, zlib/png, Python и OFL являются особыми случаями и не включены в пакет licenses. В массиве
license
они указываются так же, как и обычные лицензии (license=('BSD')
,license=('ISC')
,license=('MIT')
,license=('ZLIB')
,license=('Python')
иlicense=('OFL')
), но технически это custom-лицензии из-за особых правил в отношении авторских прав. Файл любой из этих лицензий должен храниться в каталоге/usr/share/licenses/пакет/
. - Некоторые пакеты могут распространяться сразу под несколькими лицензиями. В этом случае их все нужно указать в массиве
license
, например:license=('GPL' 'custom:лицензия')
. - У лицензии (L)GPL есть разные версии и варианты. Приняты следующие соглашения:
- (L)GPL — (L)GPLv2 или более поздняя
- (L)GPL2 — только (L)GPL2
- (L)GPL3 — (L)GPL3 или более поздняя
- Если необходимый тип лицензии определить не удаётся, в соответствии с рекомендациями из PKGBUILD.proto можно использовать
unknown
. Тем не менее, стоит отправить запрос разработчикам и уточнить условия, под которыми программа (не) распространяется.
ReadMe.txt
. Эту информацию можно извлечь в отдельный файл в процессе работы функции build()
чем-то вроде sed -n '/This software/,/ thereof./p' ReadMe.txt > LICENSE
.
См. также Nonfree applications package guidelines.
Информацию о лицензиях свободного ПО и их перспективах можно найти в следующих статьях:
- Википедия:Лицензия свободного программного обеспечения
- Википедия:Сравнение лицензий свободного ПО с открытым исходным кодом (англ.)
- Правовые вопросы для проектов свободного ПО (англ.)
- GNU Project - Различные лицензии с комментариями
- Debian - Информация о лицензиях
- Open Source Initiative - Список лицензий по названию (англ.)
groups
Группа, к которой принадлежит пакет. Например, при установке группы plasma устанавливаются все пакеты, которые в неё входят.
Зависимости
optdepends_x86_64=()
).
depends
Список пакетов, которые необходимы для сборки и работы программы. Зависимости, определяемые в функции package()
, нужны только для работы.
Версию пакета-зависимости можно ограничить операторами сравнения, например, depends=('foobar>=1.8.0')
; если ограничений несколько, то они указываются по отдельности (depends=('foobar>=1.8.0' 'foobar<2.0.0')
).
В массиве depends
указываются все зависимости верхнего уровня, в том числе и те, которые теоретически могут установиться неявно. Представьте, что пакет foo зависит от bar и baz, причём bar тоже зависит от baz. Если не указать baz как зависимость foo, положившись на "неявную" установку, это однозначно приведёт к проблемам, если в какой-то момент bar откажется от использования baz. Pacman не установит baz при чистой установке foo, или же удалит baz из системы как пакет-сироту, в результате чего foo упадёт при работе или будет работать некорректно.
В некоторых особых случаях определённые пакеты всё же можно не указывать. Так, glibc не может быть удалён, так как в системе всегда должна быть стандартная библиотека Си, а python будет в любом случае установлен, если ваш пакет зависит хотя бы от одного python-модуля, так как для последнего python по определению является зависимостью.
В число зависимостей должны быть включены пакеты, необходимые для сборки дополнительных возможностей. В противном случае такие возможности должны быть явно отключены в настройках сборки. Если этого не сделать, то будет иметь место "автомагия зависимостей", когда либо внезапно оказывается работающей какая-то возможность из-за наличия "неявных" зависимостей, либо в системе, где производилась сборка, появляются лишние пакеты, которых не было в списке зависимостей.
Если зависимость представляет собой библиотеку (например, depends=('libfoobar.so')
), то makepkg найдёт двоичный файл, которому она нужна, и определит необходимую версию библиотеки. Если указать версию явно (depends=('libfoobar.so=2')
), то автоматический поиск версии выполняться не будет.
makedepends
Список пакетов, которые нужны только для сборки пакета. Версия пакета обозначается так же, как и в массиве depends
. Если пакеты из depends
неявно используются при сборке, указывать их повторно в makedepends
не нужно.
$ LC_ALL=C pacman -Si $(pactree -rl package) 2>/dev/null | grep -q "^Groups *:.*base-devel"
makedepends
не нужно.
optdepends
Список пакетов, которые не являются необходимыми для работы программы, но могут расширить её функционал. Иногда это означает, что некоторые исполняемые файлы, предоставляемые пакетом, откажутся работать без соответствующих опциональных зависимостей [1]. Если программа может работать с помощью нескольких альтернативных зависимостей, их все нужно указать здесь, а не в массиве depends
.
Рядом с названием опциональной зависимости необходимо указать краткое описание дополнительной функциональности, которую она предоставляет:
optdepends=('cups: printing support' 'sane: scanners support' 'libgphoto2: digital cameras support' 'alsa-lib: sound support' 'giflib: GIF images support' 'libjpeg: JPEG images support' 'libpng: PNG images support')
checkdepends
Список пакетов, которые необходимы программе для различных проверок, но не во время выполнения. Формат описания пакетов тот же, что и в параметре depends
. Эти зависимости нужны только для функции check() (если она есть), вызываемой makepkg в процессе работы.
checkdepends
не нужно.
Связи между пакетами
conflicts_x86_64=()
).
provides
Список программ, функциональность которых предоставляется данным пакетом (или виртуальные пакеты вроде cron
или sh
). В системе могут быть установлены несколько пакетов с одинаковыми пунктами в provides
, если они не конфликтуют (массив conflicts
).
pkgver
и, возможно, pkgrel
). Например, если qt-foobar является изменённым пакетом qt версии 3.3.8, то необходимо указать provides=('qt=3.3.8')
; если этого не сделать, то пакеты, которые зависят от определённой версии qt, могут перестать работать. Указывать собственный pkgname
пакета не нужно, поскольку это подразумевается неявно.
conflicts
Список программ, которые, будучи установленными, создают проблемы в работе пакета. Такие пакеты (как и пакеты, "предоставляющие" их) должны быть удалены. Версии конфликтующих пакетов указываются в формате, принятом в массиве depends
.
Обратите внимание, что на конфликты проверяются и pkgname
, и массив provides
пакета. Следовательно, если ваш пакет предоставляет какую-то функциональность и другой пакет предоставляет её же, указывать этот конфликтующий пакет в conflicts
не нужно. Например:
- netbeans неявно предоставляет функциональность
netbeans
(самого себя). - netbeans-cppAUR[ссылка недействительна: package not found] предоставляет
netbeans
и конфликтует сnetbeans
. - netbeans-phpAUR[ссылка недействительна: package not found] предоставляет
netbeans
и конфликтует сnetbeans
; пакет netbeans-cppAUR[ссылка недействительна: package not found] вconflicts
не указывается, поскольку предоставляющие одинаковую функциональность пакеты и так неявно конфликтуют друг с другом.
replaces
Список устаревших программ, которые пакет должен заменить. Например, для пакета wireshark-qt используется параметр replaces=('wireshark')
. При синхронизации баз данных pacman немедленно переустанавливает пакет, если в официальных репозиториях обнаружена подходящая замена с нужным пуктом в массиве replaces
. Если вы хотите всего лишь создать альтернативную версию существующего пакета или собираетсь загрузить пакет в AUR, то лучше использовать массивы conflicts
и provides
, которые проверяются только при явной попытке установить конфликтующий пакет.
Прочие
backup
Список файлов, которые могут изменяться пользователем и по этой причине должны сохраняться во время обновления или удаления пакета. Чаще всего здесь указывают файлы настроек из каталога /etc
.
В качестве значений backup
используются относительные пути без ведущего слэша (/
). Так, вместо /etc/pacman.conf
необходимо указать etc/pacman.conf
.
Во время обновления пакета новые версии файлов будут сохраняться с расширением .pacnew (например, file.pacnew
), чтобы избежать перезаписи существующего, изменённого пользователем файла. При удалении пакета (кроме случая, когда удаление производится командой pacman -Rn
) происходит аналогичная операция — изменённые пользователем файлы сохраняются с суффиксом .pacsave (file.pacsave
).
Подробнее см. Файлы Pacnew и Pacsave.
options
Позволяет переопределить стандартное поведение makepkg, определённое файлом /etc/makepkg.conf
. Чтобы задать новый параметр, укажите его в данном массиве. Чтобы отключить параметр, добавьте перед ним символ !
.
Список доступных параметров можно найти в руководстве PKGBUILD(5).
install
Название входящего в пакет установочного сценария .install. pacman может сохранять и выполнять различные специфичные для пакета сценарии при установке, удалении и обновлении пакета. Сценарий содержит следующие функции, выполняемые на разных этапах:
pre_install
— выполняется перед извлечением файлов. Передаётся один аргумент: новая версия пакета.post_install
— выполняется после извлечения файлов. Передаётся один аргумент: новая версия пакета.pre_upgrade
— выполняется перед извлечением файлов. Передаётся два аргумента в следующем порядке: новая версия пакета, прежняя версия пакета.post_upgrade
— выполняется после извлечения файлов. Передаётся два аргумента в следующем порядке: новая версия пакета, прежняя версия пакета.pre_remove
— выполняется перед удалением файлов. Передаётся один аргумент: прежняя версия пакета.post_remove
— выполняется после удаления файлов. Передаётся один аргумент: прежняя версия пакета.
Каждая функция выполняется в chroot-окружении внутри установочного каталога pacman. Подробнее см. это обсуждение.
- Прототип .install-сценария находится в файле /usr/share/pacman/proto.install.
- pacman#Хуки работают схожим образом.
exit
. Это помешает выполнению функций.changelog
Название файла журнала изменений пакета. Следующая команда позволяет просмотреть журнал установленного пакета (при условии, что соответствующий файл существует):
$ pacman -Qc пакет
Исходный код
source
Массив со списком необходимых для сборки пакета файлов. Как правило, описывает местонахождение файлов с исходным кодом, чаще всего в виде HTTP- или FTP-ссылки. В этом параметре часто находят применение установленные ранее значения pkgname
и pkgver
(например, source=("https://example.com/$pkgname-$pkgver.tar.gz")
).
Файлы также могут находиться в одном каталоге с PKGBUILD
, в этом случае их имена напрямую добавляются в массив. Перед началом процесса сборки все указанные в source
файлы загружаются или проверяются на наличие, и если какие-то из них найдены не будут, то makepkg прекратит работу.
Файлы .install распознаются makepkg автоматически и включать их в source
не нужно. Файлы с суффиксами .sig, .sign и .asc makepkg опознаёт как PGP-подписи и проверяет с их помощью целостность соответствующих файлов.
source=('уникальное_название_пакета::ссылка_на_файл')
. Пример: source=("$pkgname-$pkgver.tar.gz::https://github.com/coder/program/archive/v$pkgver.tar.gz")
.
- Можно указать массив
source
для конкретной архитектуры, добавив к названию символ подчёркивания и архитектуру (например,source_x86_64=()
). Каждому такому массиву должен соответствовать массив проверки целостности по контрольным суммам, например,sha256sums_x86_64=()
. - Некоторые серверы ограничивают загрузку, фильтруя запросы по строке User-Agent; это можно обойти с помощью DLAGENTS.
- С помощью URL типа
file://
можно указать вsource
название находящегося на вашем компьютере файла или каталога. Так, ссылка на локальный git-репозиторий будет иметь вид"$pkgname"::"git+file:///путь/к/репозиторию"
. - Подробнее об VCS-опциях (вроде работы с отдельной веткой git или коммитом) см. PKGBUILD(5) § USING VCS SOURCES и VCS package guidelines#VCS sources .
noextract
Массив со списком файлов из source
, которые makepkg не должен извлекать из архива. Используется, если архив не может быть распакован стандартной утилитой /usr/bin/bsdtar
или же устанавливается "как есть". Если используется другая утилита для разархивации (например, lrzip), добавьте её в массив makedepends
, а в первой строке функции prepare() извлеките исходники вручную, например:
prepare() { lrzip -d исходник.tar.lrz }
Обратите внимание, что хотя source
принимает в качестве значений ссылки, в noextract
могут указываться только имена файлов:
source=("http://foo.org/bar/foobar.tar.xz") noextract=('foobar.tar.xz')
Чтобы не извлекать вообще ничего, можно сделать следующее:
- Если
source
содержит только URL-ссылки без каких либо имён файлов, обрежьте всё до последнего символа слэша включительно:
noextract=("${source[@]##*/}")
- Если
source
содержит только имена файлов, обрежьте часть после разделителя::
(взято из файла PKGBUILD firefox-i18n):
noextract=("${source[@]%%::*}")
validpgpkeys
Массив с PGP-отпечатками. Если указать этот параметр, makepkg будет принимать подписи только от указанных в нём ключей, игнорируя связку ключей (keyring). Если файл исходников подписан подключом, makepkg будет по прежнему использовать основной ключ для сравнения.
В качестве значений принимаются только полные отпечатки в верхнем регистре. Пробельные символы недопустимы.
gpg --list-keys --fingerprint <KEYID>
.Подробнее см. makepkg#Проверка цифровых подписей.
Целостность
Перечисленные ниже переменные представляют собой массивы строк контрольных сумм, которые используются для проверки на целостность соответствующих файлов из массива source. Если вместо контрольной суммы указать значение SKIP
, то соответствующий файл проверяться не будет.
Типы и значения контрольных сумм должны предоставляться разработчиками программы, например, в объявлении о релизе. Если доступны несколько типов сумм, следует выбирать более надёжную: sha256
вместо sha1
, а sha1
вместо md5
. Целостность файлов лучше проверять сразу после загрузки.
Значения переменных можно сгенерировать опцией makepkg -g
/--geninteg
; как правило, они добавляются командой makepkg -g >> PKGBUILD
. Утилита updpkgsums
из пакета pacman-contrib позволяет обновить значения переменных, когда они уже заданы в файле PKGBUILD
. Оба инструмента используют те типы контрольных сумм, которые уже указаны в PKGBUILD
, или md5sums
, если ни одна переменная не задана.
Метод проверки целостности можно задать опцией INTEGRITY_CHECK
в файле /etc/makepkg.conf
. Подробнее см. makepkg.conf(5).
source
для конкретной архитектуры, указав её название через символ подчёркивания (например, sha256sums_x86_64=()
).
md5sums
Массив 128-битных контрольных сумм MD5 для файлов из массива source
.
sha1sums
Массив 160-битных контрольных сумм SHA-1 для файлов из массива source
.
sha256sums
Массив контрольных сумм SHA-2 с размером дайджеста 256 битов.
sha224sums, sha384sums, sha512sums
Массив контрольных сумм SHA-2 с размерами дайджеста 224, 384 и 512 битов соответственно. Редко используемые альтернативы sha256sums
.
b2sums
Массив контрольных сумм BLAKE2 с размером дайджеста 512 битов.
Смотрите также
- Руководство PKGBUILD(5).
- Пример файла PKGBUILD.