- Home
- Packages
- Forums
- Wiki
- Bugs
- AUR
- Download

# PKGBUILD (Русский)

From ArchWiki

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

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

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

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

### epoch

Целое значение, специфичное для Arch Linux, представляющее, в противоположность номерам версий, "жизненный цикл" пакета. Данное значение позволяет переопределить стандартные правила сравнения версий для тех пакетов, версии которых несовместимы с указанными правилами, когда это требуется [чтобы избежать конфликта версий] при откате версии пакета назад, изменении схемы нумерации версий и т.д. По умолчанию предполагается, что текущая эпоха (поколение) имеет значение 0. Не используйте подобную нумерацию, если вы не знаете, что вы делаете.

### pkgbase

An optional global directive is available when building a split package, pkgbase is used to refer to the group of packages in the output of makepkg and in the naming of source-only tarballs. If not specified, the first element in the pkgname array is used. All options and directives for the split packages default to the global values given in the PKGBUILD. Nevertheless, the following ones can be overridden within each split package's packaging function: pkgver, pkgrel, epoch, pkgdesc, arch, url, license, groups, depends, optdepends, provides, conflicts, replaces, backup, options, install and changelog. The variable is not allowed to begin with a hyphen.

### pkgdesc

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

Note: Не следуйте бездумно этому правилу, когда вы предоставляете пакеты в 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`. Однако, необходимо связаться с разработчиком для выяснения условий, под которыми программное обеспечение может (и не может) распространяться

Tip: Некоторые авторы программного обеспечения не предоставляют отдельного файла лицензии или описания правил распространения в файле ReadMe.txt. Эта информация может быть записана в отдельный файл в процессе `build` с использованием чего-то подобного: `sed -n '/This software/,/ thereof./p' ReadMe.txt > LICENSE`.

### groups

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

### depends

Массив имён пакетов, которые должны быть установлены перед тем, как это программное обеспечение можно будет запустить. Если программа требует минимальную версию зависимости, нужно использовать оператор `>=`, чтобы указать это, например, `depends=('foobar>=1.8.0')`. Нет необходимости указывать некоторые зависимости для вашего пакета, если другие пакеты, от которых зависит ваш пакет, уже имеют их в зависимостях. Например, gtk2 зависит от glib2 и glibc. Однако, не нужно указывать glibc в качестве зависимости для gtk2, поскольку он является зависимостью дляglib2.

### makedepends

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

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

### checkdepends

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

### optdepends

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

    optdepends=('cups: поддержка печати'
    'sane: поддержка сканирования'
    'libgphoto2: поддержка цифровых камер'
    'alsa-lib: поддержка звука'
    'giflib: поддержка изображений GIF'
    'libjpeg: поддержка изображений JPEG'
    'libpng: поддержка изображений PNG')

### provides

Массив имён пакетов, которым этот пакет придаёт дополнительный функционал. Пакеты, предоставляющие те же функции, могут быть установлены в то же время, если они не конфликтуют друг с другом (смотрите ниже). Если вы используете эту переменную, вы должны добавить версию (`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=('ethereal')` для пакета wireshark. После синхронизации `pacman -Sy` один пакет будет немедленно заменён на другой, совпадающий с именем в `replaces` в репозиториях. Если вы предоставляете альтернативную версию уже существующего пакета, используйте переменную `conflicts`, которая необходима при установке конфликтующего пакета.

### backup

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

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

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

### options

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

- strip - извлекает (strips) символы из двоичных файлов и библиотек. Если вы часто используете debugger в программах или библиотеках, может быть полезно отключить эту опцию
- docs - сохраняет каталоги `/doc`
- libtool - оставляет файлы libtool (`.la`) в пакетах
- emptydirs - оставляет пустые каталоги в пакетах
- zipman - сжимает страницы man и info с помощью gzip
- purge - удаляет файлы, указанные в переменной `PURGE_TARGETS` пакета
- upx - сжимает исполняемые двоичные файлы с помощью UPX. Дополнительные опции могут быть переданы UPX указанием переменной `UPXFLAGS`
- ccache - позволяет использовать `ccache` в процессе сборки. Более полезен при использовании его отрицательной формы `!ccache` с указанием пакетов, имеющих проблемы при сборке с использованием `ccache`
- distcc - позволяет использовать `distcc` в процессе сборки. Более полезен при использовании его отрицательной формы `!distcc` с указанием пакетов, имеющих проблемы при сборке с использованием `distcc`
- buildflags - позволяет использовать пользовательские `buildflags` (CFLAGS, CXXFLAGS, LDFLAGS) в процессе сборки. Более полезен при использовании его отрицательной формы `!buildflags` с указанием пакетов, имеющих проблемы при сборке с использованием пользовательских `buildflags`
- makeflags - позволяет использовать пользовательские `makeflags` в процессе сборки. Более полезен при использовании его отрицательной формы `!makeflags` с указанием пакетов, имеющих проблемы при сборке с использованием пользовательских `makeflags`

### install

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

- pre_install - скрипт запускается перед распаковкой файлов. Необходим один аргумент: новая версия пакета
- post_install - скрипт запускается после распаковки файлов. Необходим один аргумент: новая версия пакета
- pre_upgrade - скрипт запускается перед распаковкой файлов. Необходимо два аргумента в следующем порядке: новая версия пакета, старая версия пакета
- post_upgrade - скрипт запускается после распаковки файлов. Необходимо два аргумента в следующем порядке: новая версия пакета, старая версия пакета
- pre_remove - скрипт запускается перед удалением файлов. Необходим один аргумент: старая версия пакета
- post_remove - скрипт запускается после удаления файлов. Необходим один аргумент: старая версия пакета

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

Tip: Прототип файла `.install` есть в `/usr/share/pacman/proto.install`

### changelog

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

    pacman -Qc pkgname

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

### source

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

Note: Если вам необходимо предоставить файлы, которые не могут быть скачаны, например, различные патчи, просто разместите их в том же каталоге, в котором находится ваш файл `PKGBUILD`, и добавьте имя файла в этот массив. Все пути, добавленные здесь, считаются относительными к каталогу, в котором находится `PKGBUILD`. Перед запуском процесса сборки все фалы, прописанные в этом массиве, будут скачаны или проверены на существование, и `makepkg` не будет продолжать свою работу, если какой-либо из них не существует
Tip: Вы можете задать другое имя скачиваемому файлу: если скачанный файл имеет по каким-либо причинам плохое имя, используйте следующий синтаксис: `filename::fileuri`, например, `$pkgname-$pkgver.zip::http://199.91.152.193/7pd0l2tpkidg/jg2e1cynwii/Warez_collection_16.4.exe`

### noextract

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

    cd "$srcdir/$pkgname-$pkgver"
    unzip [source].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[@]##*/})

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

### md5sums

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

### sha1sums

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

### sha256sums, sha384sums, sha512sums

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

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

- Пример файла PKGBUILD
- Пример файла .install

Retrieved from "https://wiki.archlinux.org/index.php?title=PKGBUILD_(Русский)&oldid=247759"
Categories:

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

## Navigation menu