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

# PKGBUILD (Русский)

From ArchWiki

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

- Arch packaging standards (Русский)
- Arch Build System (Русский)
- Создание пакетов
- Категория:Разработка пакетов
- pacman/Советы и приёмы
- Arch User Repository (Русский)
- makepkg (Русский)
- pacman (Русский)

Эта страница нуждается в сопроводителе

Статья не гарантирует актуальность информации. Помогите русскоязычному сообществу поддержкой подобных страниц. См. Команда переводчиков 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`. Смотрите makepkg.conf(5).

Примечание: В алгоритме 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 (Русский)
- Русский