PKGBUILD (Русский)

PKGBUILD — файл описания сборки пакета Arch Linux (по сути, это обычный bash-скрипт), используемый для создания пакетов.

Пакеты в Arch Linux собираются при помощи утилиты makepkg и информации, размещенной в файлах PKGBUILD. Когда запускается makepkg, он ищет PKGBUILD в текущем каталоге и следует инструкциям из него, чтобы либо скомпилировать код, либо каким-либо другим образом получить файлы для сборки пакета (имя_пакета.pkg.tar.xz). Готовый пакет содержит бинарные файлы и инструкции по установке, и может быть легко установлен при помощи pacman.

В этой статье приведены переменные, которые используются в файлах PKGBUILD. Для получения информации о функциях PKGBUILD обратитесь к разделу Создание пакетов#Использование исходного кода.

Переменные

Далее будут приведены описания переменных PKGBUILD. Переменные pkgname, pkgver, pkgrel и arch являются обязательными. license не является строго необходимой для сборки пакета, но рекомендуется для любых файлов PKGBUILD, которые вы желаете распространять. makepkg будет выводить предупреждение, если эта переменная не указана.

Общепринятой практикой является определение переменных в PKGBUILD в том порядке, в котором они приведены здесь. Однако, это не обязательно — главное, чтобы использовался корректный синтаксис Bash.

pkgname

Имя пакета. Оно может состоять из латинских букв, цифр, а также следующих символов: @, ., _, +, - (собака, точка, знак подчеркивания, плюс, дефис). Все буквы должны быть строчными, а имена не должны начинаться с дефиса. Для единообразия, pkgname должен совпадать с именем архива с исходным кодом программы, которую вы упаковываете. Например, если программа находится в foobar-2.5.tar.gz, переменная pkgname должна иметь значение foobar. Имя текущего каталога сборки, в котором находится файл PKGBUILD, также должно совпадать с pkgname.

pkgver

Версия пакета. Это значение должно совпадать с номером версии пакета, выпущенного его автором. Оно может содержать буквы, цифры, точки и знаки подчеркивания, но НЕ МОЖЕТ содержать дефисы. Если автор пакета использует дефис в своей схеме нумерации пакетов, замените его знаком подчеркивания. Например, если есть версия 0.99-10, она должна быть изменена на 0.99_10. Если переменная pkgver используется позднее в PKGBUILD, знак подчеркивания может быть легко заменен на дефис при использовании, например:

source=($pkgname-${pkgver//_/-}.tar.gz)
Важно: Если в выпусках программы используется обозначение версий по датам, например, 05102014, обязательно используйте обратный порядок следования, т.е. 20141005 (формат ISO 8601). В противном случае новые версии пакета не будут считаться более свежими.

pkgrel

Номер сборки самого пакета, специфичный для Arch Linux. Это значение позволяет пользователям различать сборки одной и той же версии пакета. Когда появляется новая версия пакета, номер сборки начинается с 1. Если производятся улучшения или оптимизации в файле PKGBUILD, пакет должен быть перевыпущен, и номер сборки при этом увеличивается на 1. Когда выйдет новая версия пакета, номер сборки снова будет сброшен до 1.

pkgdir

Эта переменная описывает путь к корневому каталогу того, что должно быть упаковано. Обычно используется так: make DESTDIR="$pkgdir" install. Значение этой переменной не должно изменяться никакой функцией в PKGBUILD (prepare(), build(), check(), и т. д.).

epoch

Используется для того, чтобы версия пакета принудительно воспринималась как наиболее свежая по сравнению со всеми другими версиями, у которых указано меньшее значение epoch (невзирая на их номера). Эта переменная должна иметь целое положительное значение; если она не указана, считается, что ее значение равно 0. Она полезна, когда схема нумерации версий пакета меняется (или является буквенно-цифровой), что не позволяет корректно выполнить нормальное сравнение версий. Для получения дополнительной информации о сравнении версий смотрите страницу справочного руководства pacman(8).

Важно: Не используйте переменную epoch, если не осведомлены о возможных последствиях.

pkgbase

Необязательная глобальная переменная, доступная при сборке разделенного пакета. Используется для обращения к группе пакетов в выводе makepkg и в именах архивов с одними лишь исходными файлами. Если не указана, будет использоваться первый элемент массива pkgname. Все опции и указания для раздельных пакетов ставятся по умолчанию глобальным переменным, данным в PKGBUILD. Тем не менее, следующие из них могут быть заменены в функциях отдельных пакетов: pkgver, pkgrel, epoch, pkgdesc, arch, url, license, groups, depends, optdepends, provides, conflicts, replaces, backup, options, install и changelog. В этой переменной не допускается использование в самом начале символа дефиса.

pkgdesc

Описание пакета. Оно должно состоять не более, чем из 80 символов, и не должно содержать имя пакета. Например, вместо "Nedit — текстовый редактор для X11" следует написать просто: "Текстовый редактор для X11".

Обратите внимание: Не следуйте бездумно этому правилу, когда вы предоставляете пакеты в AUR. Если по какой-либо причине имя пакета отличается от названия приложения, включение полного названия в описание может быть единственным способом, чтобы дать пользователям возможность найти этот пакет через поиск.

arch

Массив с именами архитектур, на которых можно осуществить сборку с данным файлом PKGBUILD и в итоге работать с пакетом. В настоящее время он может содержать значения i686 и/или x86_64 (arch=('i686' 'x86_64')). Также можно использовать значение any для пакетов, не зависящих от архитектуры.

Вы можете узнать архитектуру машины, на которой производится сборка, с помощью переменной $CARCH, а также при определении переменных. Смотрите также FS#16352. Пример:

depends=('foobar')
if test "$CARCH" == x86_64; then
  depends+=('lib32-glibc')
fi

url

Адрес официального сайта упаковываемого программного обеспечения.

license

Лицензия, под которой распространяется программное обеспечение. В пакете licenses из официальных репозиториев содержится множество наиболее известных лицензий, которые устанавливаются в каталог /usr/share/licenses/common. Если пакет распространяется под одной из этих лицензий, переменной должно быть присвоено имя соответствующего каталога, например, license=('GPL'). Если требуемая лицензия не включена в официальный пакет licenses, вы должны сделать несколько вещей:

  1. Файл(ы) лицензии должен(ны) быть включен(ы) в каталог /usr/share/licenses/pkgname/, например, /usr/share/licenses/foobar/LICENSE.
  2. Если архив с исходным кодом НЕ содержит условий лицензии, а с ее условиями можно ознакомиться в другом месте, например, на веб-сайте, вы должны скопировать лицензию в файл и включить ее в архив.
  3. Добавьте custom в массив license. Также вы можете заменить custom на custom:имя лицензии. Как только лицензия будет использована в двух и более пакетах из официальных репозиториев (включая [community]), она станет частью пакета licenses
  • Лицензии BSD, MIT, zlib/png и Python являются отдельными случаями и не могут быть включены в пакет licenses. Ради массива license они рассматриваются как текущие лицензии (license=('BSD'), license=('MIT'), license=('ZLIB') и license=('Python')), но технически каждая из них является пользовательской, потому что содержит свой собственный копирайт. Любые пакеты, распространяющиеся под одной из этих четырех лицензий, должны иметь свою собственную уникальную лицензию, расположенную в /usr/share/licenses/pkgname. Некоторые пакеты могут распространяться не только под одной лицензией. В этих случаях вы можете создавать несколько записей в массиве license, например, license=('GPL' 'custom:имя лицензии ')
  • (L)GPL имеет много версий и редакций этих версий. Для программного обеспечения, распространяемого под (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.

groups

Группа, к которой принадлежит пакет. Например, когда вы устанавливаете пакет kdebase, он устанавливает все пакеты, принадлежащие группе kde.

depends

Массив имен пакетов, которые должны быть установлены для запуска программы из данного пакета. Диапазоны совместимых версий можно указать при помощи операторов сравнения, например: depends=('foobar>=1.8.0'). если необходимо указать несколько ограничений, зависимость можно повторить для каждого из них [1], например: depends=('foobar>=1.8.0' 'foobar<2.0.0').

Указывать версии пакетов не обязательно. Нет необходимости указывать некоторые зависимости для вашего пакета, если другие пакеты, от которых зависит ваш пакет, уже имеют их в зависимостях. Например, gtk2 зависит от glib2 и glibc. Однако, не нужно указывать glibc в качестве зависимости для gtk2, поскольку он является зависимостью для glib2.

optdepends

Массив имен пакетов, которые не требуются для работы программы, но предлагают дополнительные функции. Также должно быть указано короткое описание того, что дает каждый пакет. optdepends может выглядеть, как здесь:

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'
)

makedepends

Массив имен пакетов, которые должны быть установлены для сборки пакета, но не нужны для использования программы после установки. Вы можете указать минимальную версию зависимости для пакетов в том же формате, что и в массиве depends.

Обратите внимание: Указание пакетов, которые уже есть в массиве depends, необязательно.
Важно: Предполагается, что группа base-devel уже установлена для сборки при помощи makepkg. Пакеты группы "base-devel" не должны включаться в массивы makedepends.

checkdepends

Массив пакетов, от которых зависит запуск собственных тестов пакета, но ненужных во время выполнения. Пакеты в этом списке должны иметь такой же формат, как и в depends. Эти зависимости должны быть прописаны, только если функция check() включена и должна запускаться в makepkg.

Важно: Предполагается, что группа base-devel уже установлена для сборки при помощи makepkg. Пакеты группы "base-devel" не должны включаться в массивы makedepends.

provides

Массив имен пакетов, которым этот пакет придает дополнительный функционал (или виртуальный пакет вроде cron или sh). Пакеты, предоставляющие одни и те же функции, могут быть установлены в одно время, если они не конфликтуют друг с другом (смотрите ниже).

Важно: Если вы используете эту переменную, вы должны добавить версию (pkgver и, возможно, номер сборки pkgrel), которую этот пакет предоставит, если это затрагивает зависимости. Например, если вы создали модифицированный пакет qt, названный qt-foobar, который имеет версию 3.3.8, и предоставляет, соответственно, qt, массив provides должен выглядеть так: provides=('qt=3.3.8'). Если написать provides=('qt'), могут быть нарушены те зависимости, которые требуют конкретную версию qt. Не добавляйте pkgname в ваш массив provides, это будет сделано автоматически.

conflicts

Массив имен пакетов, которые могут вызвать проблемы при наличии в системе. Пакет с этим именем, а также все пакеты, которые предоставляют (provides) виртуальные пакеты с этим именем, будут удалены. Вы также можете указать версии конфликтующих пакетов в том же формате, что и в массиве depends.

replaces

Массив устаревших имен пакетов, которые замещаются этим пакетом, например, replaces=('wireshark') для пакета wireshark[broken link: replaced by wireshark-gtk]. После синхронизации pacman -Sy один пакет будет немедленно заменен на другой, совпадающий с именем в replaces в репозиториях. Если вы предоставляете альтернативную версию уже существующего пакета, используйте переменную conflicts, которая необходима при установке конфликтующего пакета.

backup

Массив файлов, которые могут содержать изменения, сделанные пользователем, и должны быть сохранены в процессе обновления или удаления пакета. В первую очередь эта переменная предназначена для конфигурационных файлов в /etc.

При обновлении новая версия файла может быть сохранена как file.pacnew во избежание перезаписи старой версии файла, который уже существует и был ранее изменен пользователем. Аналогичным образом при удалении пакета файлы, измененные пользователем, будут сохранены как file.pacsave до тех пор, пока пакет не будет удален командой pacman -Rn.

Пути к файлам в этом массиве должны быть относительными (например, etc/pacman.conf), а не абсолютными (например, /etc/pacman.conf). Смотрите также статью Файлы Pacnew и Pacsave.

options

Этот массив позволяет вам изменить стандартное поведение makepkg, указанное в /etc/makepkg.conf. Чтобы добавить опцию, включите ее имя в массив. Чтобы инвертировать поведение на обратное, поместите ! в начало опции.

Полный список доступных опций можно найти на странице справочного руководства man PKGBUILD.

install

Имя скрипта .install, включаемого в пакет. pacman может хранить и исполнять служебные скрипты во время установки, удаления или обновления пакета. Скрипт содержит следующие функции, запускаемые в разное время:

  • pre_install — скрипт запускается перед распаковкой файлов. Передается один аргумент: новая версия пакета;
  • post_install — скрипт запускается после распаковки файлов. Передается один аргумент: новая версия пакета;
  • pre_upgrade — скрипт запускается перед распаковкой файлов. Передается два аргумента в следующем порядке: новая версия пакета, старая версия пакета;
  • post_upgrade — скрипт запускается после распаковки файлов. Передается два аргумента в следующем порядке: новая версия пакета, старая версия пакета;
  • pre_remove — скрипт запускается перед удалением файлов. Передается один аргумент: старая версия пакета;
  • post_remove — скрипт запускается после удаления файлов. Передается один аргумент: старая версия пакета.

Каждая функция запускается в сеансе chroot в установочном каталоге pacman. Смотрите подробнее на странице https://bbs.archlinux.org/viewtopic.php?pid=913891.

Совет: Вы можете использовать шаблон файла .install: /usr/share/pacman/proto.install. Также вы можете получить этот шаблон из git-репозитория pacman.

changelog

Имя файла лога изменений пакета. Для просмотра логов изменений установленных пакетов (у которых есть этот файл) выполните:

pacman -Qc имя_пакета
Совет: Шаблон файла лога изменений есть в /usr/share/pacman/ChangeLog.proto

source

Массив файлов, необходимых для сборки пакета. Он должен содержать месторасположение исходных файлов программы, которым в большинстве случаев является полный HTTP или FTP-адрес. Здесь вы можете использовать уже установленные ранее значения переменных pkgname и pkgver (например, source=("https://example.com/$pkgname-$pkgver.tar.gz")).

Обратите внимание: Если вам необходимо предоставить файлы, которые не могут быть загружены — например, различные патчи, просто разместите их в том же каталоге, в котором находится ваш файл PKGBUILD, и добавьте имя файла в этот массив. Все пути, добавленные здесь, считаются относительными к каталогу, в котором находится PKGBUILD. Перед запуском процесса сборки все файлы, прописанные в этом массиве, будут скачаны или проверены на существование, и makepkg не будет продолжать свою работу, если какой-либо из них не удалось найти.
Совет: Вы можете присвоить какое-нибудь другое имя загруженному файлу. Для этого используйте следующий синтаксис: filename::fileuri. Например:
source=("project_name::hg+https://googlefontdirectory.googlecode.com/hg/")

noextract

Массив файлов, указанных в source, которые не должны быть распакованы командой makepkg. Чаще всего это относится к архивам, которые не могут быть обработаны при помощи /usr/bin/bsdtar, поскольку libarchive обрабатывает все файлы как последовательные потоки без возможности получения случайного доступа к содержимому, как это делает unzip. В этих ситуациях в зависимостях (makedepends) следует указать другой инструмент распаковки (например, unzip, p7zip и т. д.), а функция prepare() первым делом должна извлекать исходные файлы самостоятельно:

unzip архив.zip

Заметьте, что хотя массив source принимает URL-адреса, в noextract следует указывать только имена самих файлов. Так, например, вы можете сделать что-то наподобие этого (упрощенный PKGBUILD grub2):

source=("http://ftp.archlinux.org/other/grub2/grub2_extras_lua_r20.tar.xz")
noextract=('grub2_extras_lua_r20.tar.xz')

Чтобы вообще не распаковывать ничего, вы можете сделать что-нибудь причудливое, вроде того, что здесь (взято с firefox-i18n):

noextract=("${source[@]%%::*}")
Обратите внимание: Более консервативный вариант подстановки, вероятно, будет включать циклы, которые вызывают basename. Если вы дочитали до этого места, у вас, вероятно, уже есть идея, как этого добиться ;).

md5sums

Массив контрольных сумм MD5 всех файлов, перечисленных в source. Как только все файлы из массива source становятся доступны, для каждого из них автоматически вычисляется MD5-хэш и сравнивается со значениями это массива в том же порядке, в котором они появляются в массиве source. Порядок source-файлов сам по себе не имеет значения, но важно, чтобы он совпадал с порядком в этом массиве, так как makepkg не знает, какие контрольные суммы какому файлу принадлежат. Вы можете быстро и легко сгенерировать этот массив, используя команду updpkgsums в каталоге, содержащем файл PKGBUILD.

Обратите внимание: Алгоритм MD5 считается слабым, поэтому предпочтительнее использовать более стойкие аналоги из семейства алгоритмов SHA-2 — например, SHA-256.

sha1sums

Массив 160-битных контрольных сумм SHA-1. Он является альтернативой md5sums, описанного выше. Чтобы включить проверку этих контрольных сумм, необходимо включить опцию INTEGRITY_CHECK в /etc/makepkg.conf. Смотрите man makepkg.conf.

Обратите внимание: В алгоритме SHA-1 присутствуют известные слабые места, поэтому предпочтительнее использовать более стойкие аналоги из семейства алгоритмов SHA-2 — например, SHA-256.

sha256sums, sha384sums, sha512sums

Массив контрольных сумм SHA-2 с размерами 256, 384 и 512 бит соответственно. Это альтернативы md5sums и sha1sums, описанные выше, и они считаются наиболее стойкими. Чтобы включить использование и генерацию этих контрольных сумм, убедитесь, что вы включили опцию INTEGRITY_CHECK в /etc/makepkg.conf. Смотрите страницу справочного руководства man makepkg.conf (5).

Смотрите также