PKGBUILD (Русский) - ArchWiki

# PKGBUILD (Русский)

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

- Arch Packaging Standards (Русский)
- Arch Build System (Русский)
- Создание пакетов
- Категория:Разработка пакетов
- Советы по использованию pacman
- Arch User Repository (Русский)
- Makepkg (Русский)
- pacman (Русский)

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

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

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

Categories:

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