# PKGBUILD (Русский)

Ссылки по теме

- Стандарты для создания пакетов Arch
- Система сборки для Arch
- Создание пакетов
- Категория:Разработка пакетов
- Советы по pacman
- Шаблоны PKGBUILD
- Пользовательский репозиторий Arch
- Makepkg (Русский)
- pacman (Русский)

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

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

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

## Переменные

Далее следует описание переменных, которые могут быть включены в файл 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)

### pkgrel

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

### pkgdir

Эта переменная описывает путь к корневому каталогу того, что должно быть упаковано. Обычно используется так: `make DESTDIR="$pkgdir" install`.

### 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

Лицензия, под которой распространяется программное обеспечение. В `[core]` был создан пакет licenses, который размещает все текущие лицензии в `/usr/share/licenses/common`, например, `/usr/share/licenses/common/GPL`. Если пакет распространяется под одной из этих лицензий, переменной должно быть присвоено имя соответствующего каталога, например, `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: поддержка печати'
      'sane: поддержка сканеров'
      'libgphoto2: поддержка цифровых камер'
      'alsa-lib: поддержка звука'
      'giflib: поддержка изображений GIF'
      'libjpeg: поддержка изображений JPEG'
      'libpng: поддержка изображений PNG'
    )

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

### 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. После синхронизации `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. Смотрите здесь.

Совет: Прототип файла `.install` есть в `/usr/share/pacman/proto.install`. Для получения веб-прототипа обратитесь к странице pacman's git

### changelog

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

    pacman -Qc pkgname

Совет: Прототип файла лога изменений есть в `/usr/share/pacman/ChangeLog.proto`

### source

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

Обратите внимание: Если вам необходимо предоставить файлы, которые не могут быть скачаны, например, различные патчи, просто разместите их в том же каталоге, в котором находится ваш файл `PKGBUILD`, и добавьте имя файла в этот массив. Все пути, добавленные здесь, считаются относительными к каталогу, в котором находится `PKGBUILD`. Перед запуском процесса сборки все файлы, прописанные в этом массиве, будут скачаны или проверены на существование, и `makepkg` не будет продолжать свою работу, если какой-либо из них не существует
Совет: Вы можете задать другое имя скачиваемому файлу: если скачанный файл имеет по каким-либо причинам плохое имя (например, URL-адрес имеет параметр GET), используйте следующий синтаксис: `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[@]%%::*}")

Обратите внимание: Более консервативная замена Bash, возможно, будет включать петли, которые называются `basename`. Если вы дочитали до этого места, у вас должна быть идея

### md5sums

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

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

### sha1sums

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

### sha256sums, sha384sums и sha512sums

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

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

- Страница справочного руководства PKGBUILD(5)
- Файл-пример PKGBUILD

Categories:

- Package development (Русский)
- Русский