PKGBUILD (Русский)

From ArchWiki
Jump to: navigation, search

Tango-preferences-desktop-locale.pngЭта страница нуждается в сопроводителеTango-preferences-desktop-locale.png

Статья не гарантирует актуальность информации. Помогите русскоязычному сообществу поддержкой подобных страниц. См. Команда переводчиков ArchWiki

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

PKGBUILD — это shell-скрипт, содержащий информацию, необходимую для сборки пакетов Arch Linux.

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

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

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

Имя пакета

pkgbase

Необязательная глобальная переменная, доступная при сборке разделенного пакета. Используется для обращения к группе пакетов в выводе makepkg, а также при именовании архивов с одними лишь исходными файлами. Если она не указана, будет использоваться первый элемент массива pkgname. В этой переменной нельзя использовать дефис в качестве первого символа. Все опции и указания для раздельных пакетов ставятся по умолчанию глобальным переменным, данным в PKGBUILD. Тем не менее, они все, за исключением makedepends, переменных исходного кода и проверки целостности, могут быть переопределены в функции package() каждого отдельного пакета.

pkgname

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

Имена для разделенных пакетов должны быть определены при помощи массива, например, так: pkgname=('foo' 'bar').

Версия

pkgver

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

Примечание: Если в выпусках программы используется обозначение версий по датам, например, 05102014, обязательно используйте обратный порядок следования, т.е. 20141005 (формат ISO 8601). В противном случае новые версии пакета не будут считаться более свежими
Совет: makepkg способен автоматически обновлять эту переменную, если в PKGBUILD определить функцию pkgver(). Для получения дополнительной информации смотрите раздел VCS package guidelines#The pkgver() function

pkgrel

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

epoch

Важно: Переменная epoch должна использоваться лишь в тех случаях, когда вы абсолютно уверены в ее необходимости

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

pkgver=5.13
pkgrel=2
epoch=1
1:5.13-2

Для получения дополнительной информации о сравнении версий смотрите страницу справочного руководства pacman(8).

Общие

pkgdesc

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

Также помните, что очень важно активно использовать ключевые слова, чтобы увеличить вероятность нахождения пакета при помощи поисковых запросов.

arch

Массив с именами архитектур, на которых можно осуществить сборку с данным файлом PKGBUILD и, в конечном итоге, работать с пакетом. В Arch официально поддерживаются только i686 и x86_64, но такие проекты, как, например, Arch Linux ARM, предоставляют поддержку других архитектур, таких как armv5, armv6, armv7 и armv8.

Если после компиляции пакета его работа не зависит от архитектуры (скрипты оболочки, шрифты, темы оформления, различные расширения и т.п.), используйте значение arch=('any'). Обратите внимание, что это относится к пакетам, которые можно собрать единожды и в дальнейшем использовать на любой архитектуре. В архитектуре таких пакетов будет указано -any, а не -i686, -x86_64 или что-то подобное.

Если же пакет можно скомпилировать на любой архитектуре, но после компиляции он становится архитектурозависимым, укажите все архитектуры, официально поддерживаемые в Arch, т.е. arch=('i686' 'x86_64').

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

url

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

license

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

  1. Добавьте значение custom в массив license. Также вы можете заменить custom на custom:имя лицензии. Как только лицензия будет использована в двух и более пакетах из официальных репозиториев (включая [community]), она будет включена в пакет licenses
  2. Устанавливайте лицензию в каталог /usr/share/licenses/имя_пакета/, например, /usr/share/licenses/foobar/LICENSE
  3. Если лицензию можно найти лишь на веб-сайте, все равно необходимо включить ее в пакет
  • Лицензии 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, устанавливаются все пакеты, входящие в эту группу.

Зависимости

Примечание: Вы можете использовать специфичные для разных архитектур массивы путем добавления символа подчеркивания и имени архитектуры, например, depends_x86_64=(), optdepends_x86_64=()

depends

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

Нет необходимости указывать зависимости, предоставляемые пакетами, от которых зависит ваш пакет. Например, если пакет foo зависит от bar и baz, и, в свою очередь, пакет bar зависит от baz, то не следует включать пакет baz в массив depends пакета foo.

optdepends

Массив имен пакетов, которые не требуются для работы программы, но предлагают дополнительные функции. Это может означать, что не все исполняемые файлы, предоставляемые пакетом, будут работать без соответствующих дополнительных зависимостей [2]. Если программное обеспечение может работать с разными альтернативными зависимостями, их можно указать здесь, а не в массиве 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'
)

makedepends

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

Совет: Чтобы узнать, является ли какой-либо пакет частью группы base-devel или будет ли он вытянут как зависимость других пакетов группы, вы можете использовать следующую команду:
$ pacman -Si $(pactree -rl пакет) 2>/dev/null | grep -q "^Groups *:.*base-devel"
Примечание: Предполагается, что группа base-devel уже установлена для сборки при помощи makepkg. Пакеты этой группы не должны включаться в массив makedepends

checkdepends

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

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

Отношения

Примечание: Вы можете использовать специфичные для разных архитектур массивы путем добавления символа подчеркивания и имени архитектуры, например, provides_x86_64=(), conflicts_x86_64=()

provides

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

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

conflicts

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

replaces

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

Остальные

backup

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

Пути к файлам в этом массиве должны быть относительными, без предваряющего их слеша (/) (например, etc/pacman.conf вместо /etc/pacman.conf).

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

Смотрите также статью Файлы Pacnew и Pacsave.

options

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

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

install

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

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

Каждая функция запускается в сеансе chroot в установочном каталоге pacman. Смотрите эту ветку форума.

Совет: Вы можете использовать шаблон файла .install /usr/share/pacman/proto.install

changelog

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

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

Исходные коды

source

Примечание: Вы можете использовать специфичные для разных архитектур массивы путем добавления символа подчеркивания и имени архитектуры, например, source_x86_64=(). Также должен присутствовать соответствующий массив с контрольными суммами, например, sha256sums_x86_64=()

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

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

Примечание: Файлы .install в этот массив включаться не должны
Совет: Вы можете присвоить какое-нибудь другое имя загруженному файлу. Для этого используйте следующий синтаксис: source=('filename::fileuri'):
source=("project_name::hg+https://googlefontdirectory.googlecode.com/hg/")

noextract

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

prepare() {
  lrzip -d source.tar.lrz
}

Заметьте, что, хотя массив source принимает URL-адреса, в noextract следует указывать только имена самих файлов:

source=("http://foo.org/bar/foobar.tar.xz")
noextract=('foobar.tar.xz')

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

noextract=("${source[@]%%::*}")

Целостность

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

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