arch-wiki-md-repo
Version:
All arch-wiki articles in markdown format, updated every two days.
314 lines (196 loc) • 40.3 kB
Markdown
Ссылки по теме
* [Arch packaging standards (Русский)](/index.php/Arch_packaging_standards_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Arch packaging standards (Русский)")
* [Arch Build System (Русский)](/index.php/Arch_Build_System_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Arch Build System (Русский)")
* [Создание пакетов](/index.php/%D0%A1%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2 "Создание пакетов")
* [Категория:Разработка пакетов](/index.php/Category:Package_development_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Category:Package development (Русский)")
* [pacman/Советы и приёмы](/index.php/Pacman/%D0%A1%D0%BE%D0%B2%D0%B5%D1%82%D1%8B_%D0%B8_%D0%BF%D1%80%D0%B8%D1%91%D0%BC%D1%8B "Pacman/Советы и приёмы")
* [Arch User Repository (Русский)](/index.php/Arch_User_Repository_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Arch User Repository (Русский)")
* [makepkg (Русский)](/index.php/Makepkg_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Makepkg (Русский)")
* [pacman (Русский)](/index.php/Pacman_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Pacman (Русский)")
В этой статье приведен список переменных, которые мейнтейнеры описывают в файлах PKGBUILD. Для получения информации о функциях, используемых в этих файлах, а также о создании пакетов в целом, смотрите статью [Создание пакетов](/index.php/%D0%A1%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2 "Создание пакетов").
PKGBUILD — это shell-скрипт, содержащий информацию, необходимую для сборки пакетов [Arch Linux](/index.php/Arch_Linux_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Arch Linux (Русский)").
Пакеты в Arch Linux собираются при помощи утилиты [makepkg](/index.php/Makepkg_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Makepkg (Русский)") . При запуске она ищет в текущем каталоге файл `PKGBUILD` и следует инструкциям из него, чтобы либо скомпилировать код, либо получить файлы для сборки пакета (`*имя_пакета*.pkg.tar.xz`). Готовый пакет содержит двоичные файлы и инструкции по установке, благодаря чему может быть легко установлен при помощи [pacman](/index.php/Pacman_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Pacman (Русский)").
Переменные `pkgname`, `pkgver`, `pkgrel` и `arch` являются обязательными. `license` не является строго необходимой для сборки пакета, но рекомендуется для любых файлов PKGBUILD, которые вы желаете распространять. *makepkg* будет выводить предупреждение, если эта переменная не указана.
Общепринятой практикой является определение переменных в PKGBUILD в том порядке, в котором они приведены здесь. Однако, это не обязательно — главное, чтобы использовался корректный синтаксис [Bash](/index.php/Bash_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Bash (Русский)").
## Contents
* [1 Имя пакета](#.D0.98.D0.BC.D1.8F_.D0.BF.D0.B0.D0.BA.D0.B5.D1.82.D0.B0)
* [1.1 pkgbase](#pkgbase)
* [1.2 pkgname](#pkgname)
* [2 Версия](#.D0.92.D0.B5.D1.80.D1.81.D0.B8.D1.8F)
* [2.1 pkgver](#pkgver)
* [2.2 pkgrel](#pkgrel)
* [2.3 epoch](#epoch)
* [3 Общие](#.D0.9E.D0.B1.D1.89.D0.B8.D0.B5)
* [3.1 pkgdesc](#pkgdesc)
* [3.2 arch](#arch)
* [3.3 url](#url)
* [3.4 license](#license)
* [3.5 groups](#groups)
* [4 Зависимости](#.D0.97.D0.B0.D0.B2.D0.B8.D1.81.D0.B8.D0.BC.D0.BE.D1.81.D1.82.D0.B8)
* [4.1 depends](#depends)
* [4.2 optdepends](#optdepends)
* [4.3 makedepends](#makedepends)
* [4.4 checkdepends](#checkdepends)
* [5 Отношения](#.D0.9E.D1.82.D0.BD.D0.BE.D1.88.D0.B5.D0.BD.D0.B8.D1.8F)
* [5.1 provides](#provides)
* [5.2 conflicts](#conflicts)
* [5.3 replaces](#replaces)
* [6 Остальные](#.D0.9E.D1.81.D1.82.D0.B0.D0.BB.D1.8C.D0.BD.D1.8B.D0.B5)
* [6.1 backup](#backup)
* [6.2 options](#options)
* [6.3 install](#install)
* [6.4 changelog](#changelog)
* [7 Исходные коды](#.D0.98.D1.81.D1.85.D0.BE.D0.B4.D0.BD.D1.8B.D0.B5_.D0.BA.D0.BE.D0.B4.D1.8B)
* [7.1 source](#source)
* [7.2 noextract](#noextract)
* [8 Целостность](#.D0.A6.D0.B5.D0.BB.D0.BE.D1.81.D1.82.D0.BD.D0.BE.D1.81.D1.82.D1.8C)
* [8.1 md5sums](#md5sums)
* [8.2 sha1sums](#sha1sums)
* [8.3 sha256sums, sha384sums, sha512sums](#sha256sums.2C_sha384sums.2C_sha512sums)
* [9 Смотрите также](#.D0.A1.D0.BC.D0.BE.D1.82.D1.80.D0.B8.D1.82.D0.B5_.D1.82.D0.B0.D0.BA.D0.B6.D0.B5)
## Имя пакета
### pkgbase
Необязательная глобальная переменная, доступная при сборке разделенного пакета. Используется для обращения к группе пакетов в выводе *makepkg*, а также при именовании архивов с одними лишь исходными файлами. Если она не указана, будет использоваться первый элемент массива `pkgname`. В этой переменной нельзя использовать дефис в качестве первого символа. Все опции и указания для раздельных пакетов ставятся по умолчанию глобальным переменным, данным в PKGBUILD. Тем не менее, они все, за исключением `makedepends`, переменных [исходного кода](#.D0.98.D1.81.D1.85.D0.BE.D0.B4.D0.BD.D1.8B.D0.B5_.D0.BA.D0.BE.D0.B4.D1.8B) и [проверки целостности](#.D0.A6.D0.B5.D0.BB.D0.BE.D1.81.D1.82.D0.BD.D0.BE.D1.81.D1.82.D1.8C), могут быть переопределены в функции `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](https://en.wikipedia.org/wiki/ru:ISO_8601 "wikipedia:ru:ISO 8601")). В противном случае новые версии пакета не будут считаться более свежими
**Совет:** [makepkg](/index.php/Makepkg_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Makepkg (Русский)") способен автоматически [обновлять](http://allanmcrae.com/2013/04/pacman-4-1-released/) эту переменную, если в PKGBUILD определить функцию `pkgver()`. Для получения дополнительной информации смотрите раздел [VCS package guidelines#The pkgver() function](/index.php/VCS_package_guidelines#The_pkgver.28.29_function "VCS package guidelines")
### pkgrel
Номер релиза. Это значение позволяет пользователям различать сборки одной и той же версии пакета. Когда в PKGBUILD вносятся исправления и добавляются новые возможности, влияющие на итоговый пакет, `pkgrel` должен быть увеличен на 1\. Когда же выходит новая версия программного обеспечения, это значение должно быть сброшено на 1.
### epoch
**Важно:** Переменная `epoch` должна использоваться лишь в тех случаях, когда вы абсолютно уверены в ее необходимости
Используется для того, чтобы версия пакета принудительно воспринималась как наиболее свежая по сравнению со всеми другими версиями, у которых указано меньшее значение `epoch` (невзирая на их номера). Эта переменная должна иметь целое положительное значение; если она не указана, считается, что ее значение равно 0\. Она полезна, когда схема нумерации версий пакета меняется (или является буквенно-цифровой) и необходимо обойти логику нормального сравнения версий. Например:
```
pkgver=5.13
pkgrel=2
epoch=1
```
`1:5.13-2`
Для получения дополнительной информации о сравнении версий смотрите [страницу справочного руководства](/index.php/Man_page_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Man page (Русский)") [pacman(8)](https://www.archlinux.org/pacman/pacman.8.html).
## Общие
### pkgdesc
Описание пакета. Рекомендуется использовать не более 80 символов и не использовать имя пакета, за исключением случаев, когда имя приложения отличается от имени пакета. Например, вместо `pkgdesc="Nedit — текстовый редактор для X11"` следует написать просто: `pkgdesc="Текстовый редактор для X11"`.
Также помните, что очень важно активно использовать ключевые слова, чтобы увеличить вероятность нахождения пакета при помощи поисковых запросов.
### arch
Массив с именами архитектур, на которых можно осуществить сборку с данным файлом PKGBUILD и, в конечном итоге, работать с пакетом. В Arch официально поддерживаются только `i686` и `x86_64`, но такие проекты, как, например, [Arch Linux ARM](http://archlinuxarm.org/), предоставляют поддержку других архитектур, таких как `armv5`, `armv6`, `armv7` и `armv8`.
Если после компиляции пакета его работа не зависит от архитектуры (скрипты оболочки, шрифты, темы оформления, различные расширения и т.п.), используйте значение `arch=('any')`. Обратите внимание, что это относится к пакетам, которые можно собрать единожды и в дальнейшем использовать на любой архитектуре. В архитектуре таких пакетов будет указано `-any`, а не `-i686`, `-x86_64` или что-то подобное.
Если же пакет можно скомпилировать на любой архитектуре, но после компиляции он становится архитектурозависимым, укажите все архитектуры, официально поддерживаемые в Arch, т.е. `arch=('i686' 'x86_64')`.
Вы можете узнать архитектуру машины, на которой производится сборка, с помощью переменной `$CARCH`.
### url
Адрес официального сайта упаковываемого программного обеспечения.
### license
Лицензия, под которой распространяется программное обеспечение. В пакете [licenses](https://www.archlinux.org/packages/?name=licenses) из [официальных репозиториев](/index.php/Official_repositories_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Official repositories (Русский)") содержится множество наиболее известных лицензий, которые устанавливаются в каталог `/usr/share/licenses/common`. Если пакет распространяется под одной из этих лицензий, переменной должно быть присвоено имя соответствующего каталога, например, `license=('GPL')`. Если требуемая лицензия не включена в официальный пакет [licenses](https://www.archlinux.org/packages/?name=licenses), вы должны сделать несколько вещей:
1. Добавьте значение `custom` в массив `license`. Также вы можете заменить `custom` на `custom:*имя лицензии*`. Как только лицензия будет использована в двух и более пакетах из официальных репозиториев (включая `[community]`), она будет включена в пакет [licenses](https://www.archlinux.org/packages/?name=licenses)
2. Устанавливайте лицензию в каталог `/usr/share/licenses/*имя_пакета*/`, например, `/usr/share/licenses/foobar/LICENSE`
3. Если лицензию можно найти лишь на веб-сайте, все равно необходимо включить ее в пакет
* Лицензии [BSD](https://en.wikipedia.org/wiki/ru:%D0%9B%D0%B8%D1%86%D0%B5%D0%BD%D0%B7%D0%B8%D1%8F_BSD "wikipedia:ru:Лицензия BSD"), [MIT](https://en.wikipedia.org/wiki/ru:%D0%9B%D0%B8%D1%86%D0%B5%D0%BD%D0%B7%D0%B8%D1%8F_MIT "wikipedia:ru:Лицензия MIT"), [zlib/png](https://en.wikipedia.org/wiki/ru:%D0%9B%D0%B8%D1%86%D0%B5%D0%BD%D0%B7%D0%B8%D1%8F_zlib "wikipedia:ru:Лицензия zlib") и [Python](https://en.wikipedia.org/wiki/Python_License "wikipedia:Python License") являются отдельными случаями и не могут быть включены в пакет [licenses](https://www.archlinux.org/packages/?name=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](https://projects.archlinux.org/pacman.git/tree/proto/PKGBUILD.proto) предлагает использовать значение `unknown`. Однако, необходимо связаться с разработчиком для выяснения условий, под которыми программное обеспечение может (и не может) распространяться
**Совет:** Некоторые авторы программного обеспечения не предоставляют отдельного файла лицензии, а описывают правила распространения в разделе файла `ReadMe.txt`. Эта информация может быть записана в отдельный файл в процессе выполнения функции `build()` при помощи команды наподобие `sed -n '/**This software**/,/ **thereof.**/p' ReadMe.txt > LICENSE`
### groups
[Группа](/index.php/Pacman_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9)#.D0.A3.D1.81.D1.82.D0.B0.D0.BD.D0.BE.D0.B2.D0.BA.D0.B0_.D0.B3.D1.80.D1.83.D0.BF.D0.BF.D1.8B_.D0.BF.D0.B0.D0.BA.D0.B5.D1.82.D0.BE.D0.B2 "Pacman (Русский)"), к которой принадлежит пакет. Например, когда вы пытаетесь установить пакет [kdebase](https://www.archlinux.org/groups/x86_64/kdebase/), устанавливаются все пакеты, входящие в эту группу.
## Зависимости
**Примечание:** Вы можете использовать специфичные для разных архитектур массивы путем добавления символа подчеркивания и имени архитектуры, например, `depends_x86_64=()`, `optdepends_x86_64=()`
### depends
Массив имен пакетов, которые должны быть установлены для запуска программы из данного пакета. Диапазоны совместимых версий можно указать при помощи операторов сравнения (пример: `depends=('foobar>=1.8.0')`). Если необходимо указать несколько ограничений, зависимость можно повторить для каждого из них [[1]](https://mailman.archlinux.org/pipermail/arch-general/2012-July/029022.html) (пример: `depends=('foobar>=1.8.0' 'foobar<2.0.0')`).
Нет необходимости указывать зависимости, предоставляемые пакетами, от которых зависит ваш пакет. Например, если пакет *foo* зависит от *bar* и *baz*, и, в свою очередь, пакет *bar* зависит от *baz*, то не следует включать пакет *baz* в массив `depends` пакета *foo*.
### optdepends
Массив имен пакетов, которые не требуются для работы программы, но предлагают дополнительные функции. Это может означать, что не все исполняемые файлы, предоставляемые пакетом, будут работать без соответствующих дополнительных зависимостей [[2]](https://lists.archlinux.org/pipermail/arch-general/2014-December/038124.html). Если программное обеспечение может работать с разными альтернативными зависимостями, их можно указать здесь, а не в массиве `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](https://www.archlinux.org/groups/x86_64/base-devel/) или будет ли он вытянут как зависимость других пакетов группы, вы можете использовать следующую команду:
```
$ pacman -Si $(pactree -rl *пакет*) 2>/dev/null | grep -q "^Groups *:.*base-devel"
```
**Примечание:** Предполагается, что группа [base-devel](https://www.archlinux.org/groups/x86_64/base-devel/) уже установлена для сборки при помощи *makepkg*. Пакеты этой группы **не должны** включаться в массив `makedepends`
### checkdepends
Массив имен пакетов, от которых зависит запуск собственных тестов пакета, но ненужных для его последующей работы. Пакеты в этом списке должны иметь такой же формат, как и в `depends`. Эти зависимости должны быть прописаны, только если *makepkg* должен выполнять функцию [check()](/index.php/Creating_packages#check.28.29 "Creating packages").
**Примечание:** Предполагается, что группа [base-devel](https://www.archlinux.org/groups/x86_64/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](https://www.archlinux.org/packages/?name=wireshark-gtk) используется `replaces=('wireshark')`. После синхронизации *pacman* немедленно заменит установленный пакет на другой, из репозиториев, с соответствующей записью в `replaces`. Если вы предоставляете альтернативную версию уже существующего пакета или загружаете его в [AUR](/index.php/Arch_User_Repository_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Arch User Repository (Русский)"), используйте массивы `conflicts` и `provides`, которые необходимы только при установке конфликтующего пакета.
## Остальные
### backup
Массив имен файлов, которые могут содержать изменения, сделанные пользователем, и должны быть сохранены в процессе обновления или удаления пакета. В первую очередь эта переменная предназначена для конфигурационных файлов в `/etc`.
Пути к файлам в этом массиве должны быть **относительными**, без предваряющего их слеша (`/`) (например, `etc/pacman.conf` вместо `/etc/pacman.conf`).
При обновлении новая версия файла может быть сохранена как `файл.pacnew` во избежание перезаписи старой версии файла, который уже существует и был ранее изменен пользователем. Аналогичным образом при удалении пакета файлы, измененные пользователем, будут сохранены как `файл.pacsave` до тех пор, пока пакет не будет удален командой `pacman -Rn`.
Смотрите также статью [Файлы Pacnew и Pacsave](/index.php/%D0%A4%D0%B0%D0%B9%D0%BB%D1%8B_Pacnew_%D0%B8_Pacsave "Файлы Pacnew и Pacsave").
### options
Этот массив позволяет вам изменить стандартное поведение *makepkg*, указанное в `/etc/makepkg.conf`. Чтобы добавить опцию, включите ее имя в массив. Чтобы инвертировать поведение на обратное, поместите **`!`** в начало опции.
Полный список доступных опций можно найти на странице справочного руководства [PKGBUILD(5)](https://www.archlinux.org/pacman/PKGBUILD.5.html).
### install
Имя скрипта `.install`, включаемого в пакет. Должно быть таким же, как в `pkgname`. *pacman* может хранить и исполнять специфичные для пакета скрипты во время установки, удаления или обновления пакета. Скрипт содержит следующие функции, запускаемые в разное время:
* `pre_install` — скрипт запускается перед распаковкой файлов. Передается один аргумент: новая версия пакета;
* `post_install` — скрипт запускается после распаковки файлов. Передается один аргумент: новая версия пакета;
* `pre_upgrade` — скрипт запускается перед распаковкой файлов. Передается два аргумента в следующем порядке: новая версия пакета, старая версия пакета;
* `post_upgrade` — скрипт запускается после распаковки файлов. Передается два аргумента в следующем порядке: новая версия пакета, старая версия пакета;
* `pre_remove` — скрипт запускается перед удалением файлов. Передается один аргумент: старая версия пакета;
* `post_remove` — скрипт запускается после удаления файлов. Передается один аргумент: старая версия пакета.
Каждая функция запускается в сеансе [chroot](/index.php/Change_root_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Change root (Русский)") в установочном каталоге *pacman*. Смотрите [эту ветку форума](https://bbs.archlinux.org/viewtopic.php?pid=913891).
**Совет:** Вы можете использовать шаблон файла `.install` [/usr/share/pacman/proto.install](https://projects.archlinux.org/pacman.git/plain/proto/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](https://www.archlinux.org/packages/?name=lrzip)), он должен быть добавлен в массив `makedepends`, а первая строка функции [prepare()](/index.php/Creating_packages#prepare.28.29 "Creating packages") должна извлекать исходные файлы самостоятельно:
```
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](https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/firefox-i18n#n123)):
```
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)](http://jlk.fjfi.cvut.cz/arch/manpages/man/makepkg.conf.5).
**Примечание:** В алгоритме SHA-1 присутствуют известные слабые места, поэтому предпочтительнее использовать более стойкие аналоги из семейства алгоритмов SHA-2 — например, SHA-256.
### sha256sums, sha384sums, sha512sums
Массив контрольных сумм SHA-2 с размерами 256, 384 и 512 бит соответственно. Это альтернативы `md5sums` и `sha1sums`, описанные выше, и они считаются наиболее стойкими. Чтобы включить использование и генерацию этих контрольных сумм, убедитесь, что вы включили опцию `INTEGRITY_CHECK` в `/etc/makepkg.conf`. Смотрите [страницу справочного руководства](/index.php/Man_page_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) "Man page (Русский)") `man makepkg.conf (5)`.
## Смотрите также
* [Страница справочного руководства PKGBUILD(5)](https://www.archlinux.org/pacman/PKGBUILD.5.html)
* [Пример PKGBUILD](http://ix.io/66p)