---
category: ru
type: paper
hastr: false
layout: paper
tags: archlinux
title: Немного об Arch User Repository
short: about-aur
---
Статья посвященная работе с пользовательским репозиторием Archlinux. Постарался
сделать акцент на сопровождении пакетов. Данная статья, в большей степени,
представляет собой компиляцию нескольких англоязычных статей Wiki и немного
личного опыта. Поэтому не уверен, что в данной статье на английском языке будет
толк.

<!--more-->

## <a href="#aur" class="anchor" id="aur"><span class="octicon octicon-link"></span></a>AUR

Итак, [Arch User Repository](//aur.archlinux.org/ "AUR") (AUR или АУР) - это
репозиторий, поддерживаемый и развиваемый практически исключительно сообществом
Archlinux. Есть еще отдельные люди, называемые [доверенными
пользователями](//www.archlinux.org/trustedusers/ "Доверенные пользователи")
(TU), на плечах которых лежит своеобразная "модерация" этого репозитория. На мой
скромный взгляд, едва ли не единственное отличие Archlinux от других
дистрибутивов - это наличие AUR'а. Отличие этого репозитория от обычных прежде
всего в том, что он **не содержит** архивов с исходниками или собранных пакетов
- только скрипт сборки (PKGBUILD) и, возможно, дополнительные текстовые файлы.

Конечно, вручную скачивать архив с сайта AUR'а, а также проверять обновления, не
совсем удобно, поэтому существует [набор
хелперов](//wiki.archlinux.org/index.php/AUR_Helpers "ArchWiki"). Большинство
хелперов представляет собой обертку над pacman. Я выделю только два -
[packer](//aur.archlinux.org/packages/packer/ "AUR") - минималистичный, удобный,
быстрый - и [yaourt](//aur.archlinux.org/packages/yaourt/ "AUR") - на шелле, но
зато более функциональный. По не особо понятным мне причинам, в русскоязычном
сегменте большее распространение получил yaourt, зарубежом - packer.

Помимо хелперов, существуют также консольные клиенты для работы с AUR. Я выделю,
пожалуй, только один - [python-aur](//aur.archlinux.org/packages/python3-aur/
"AUR"). Иногда удобная альтернатива веб-интерфейсу.

Другая особенность данного репозитория - и не менее важная - **все действия с
ним осуществляются на свой страх и риск**. Опасные и некорректные пакеты,
конечно же, удаляются, но вполне могут быть и ошибки при сборке и еще все, что
сможете придумать. Дык вот - работа с ним на вашей совести, и никто вам ничем не
обязан, если что-то сломается. По этой же причине, ни один хелпер в обозримом
будущем не будет перенесен в официальные репозитории.

У пакетов в AUR есть несколько характеристик, которых нет у пакетов в
официальных репозиториях:

* группа - скорее для удобства поиска, сортировки. Немного помогает доверенным
пользователям.
* автор, мейнтейнер, последний приславший - люди, кто, соответственно, первый
раз прислал данный пакет, сопровождает его в настоящий момент, и последний
прислал.
* голоса - когда кому-либо понравился этот пакет или он находит его полезным, он
голосует. Теоретически, пакеты, имеющие больше 10 голосов могут попасть в
официальные репозитории (если найдется желающий среди доверенных пользователей).
Другой путь в официальные репозитории - попасть в [список часто
используемых](//www.archlinux.de/?page=PackageStatistics "Статистика"), но вы же
не пользуетесь [pkgstats](//www.archlinux.org/packages/pkgstats "Пакет
Archlinux").


## <a href="#install-from-aur" class="anchor" id="install-from-aur"><span class="octicon octicon-link"></span></a>Установка с AUR

Для работы с AUR требуется установить группу пакетов
[base-devel](//www.archlinux.org/groups/x86_64/base-devel/ "Группа пакетов
Archlinux"). Пакеты с этой группы, как правило, **не включены** в зависимости.
Рекомендуемая установка пакетов с AUR выглядит примерно так:

```bash
# скачать архив с PKGBUILD'ом c AUR
curl -L -O //aur.archlinux.org/packages/fo/foo/foo.tar.gz
cd foo
# отредактировать / проверить PKGBUILD
vi PKGBUILD
# собрать пакет. Флаг -c удалить директорию сборки,
# -s установить недостающие зависимости,
# -r удалить их после установки,
# -f перезаписать существующий пакет, если он есть
makepkg -csrf
# установить его
pacman -U foo-0.1-1-i686.pkg.tar.xz
```

## <a href="#upload-to-aur" class="anchor" id="upload-to-aur"><span class="octicon octicon-link"></span></a>Загрузка пакета в AUR

**Никаких** `makepkg -S`. С недавних пор данный метод считается устаревшим. Но
обо всем по-порядку

Нам нужно загрузить архив на сайт. В этом архиве **должны быть** PKGBUILD и
.AURINFO. По поводу первого я расскажу еще чуть ниже, второй генерируется
автоматически. Также, там могут быть установочные скрипты (\*.install), патчи,
файлы лицензии (если не предоставляются апстримом с исходниками), сервисы
systemd, скрипты запуска - это то, что обычно включено. **Никаких исходников**.
И тем более **никаких бинарников**. (Шутки-шутками, а я помню пакет, в котором
исходный код записывался с помощью `cat << EOF` прямо в тексте PKGBUILD'а.)

Все файлы кладем в одну директорию. Убедились, что install файл, если он есть,
указан в переменной install, все другие исходные файлы указаны в массиве source,
а хэш-суммы правильные (их легко можно сгенерировать, набрав `makepkg -g`).
Далее из этой директории запустить команду `mkaurball` (пакет
[pkgbuild-introspection](//www.archlinux.org/packages/pkgbuild-introspection
"Пакет Archlinux")) - и архив готов.

Несколько правил загрузки пакета в AUR:

* Если такой пакет существует в официальном репозитории (любой версии), то **не
нужно** заливать новый пакет. Если репозиторный пакет устарел, просто пометьте
его, как устаревший. Исключение из этого правила составляют пакеты из системы
контрля версий (VCS), о них чуть ниже.
* Проверьте AUR. Если такой пакет уже существует и у него есть мейнтейнер, вы
**не сможете залить** свой пакет. Если у него нет мейнтейнера, то вы
автоматически будете его сопровождающим после обновления. Еще может быть такой
же пакет, но с другим названием, будьте внимательны.
* PKGBUILD должен следовать (более-менее) стандартам и должен быть более-менее
аккуратным. В противном случае, пакет может быть удален без предупреждения.
* Пакет должен быть полезен еще кому-либо кроме Вас =)
* Рекомендуется проверить **собранный пакет и PKGBUILD** с помощью
[namcap](//www.archlinux.org/packages/namcap "Пакет Archlinux"). Это не даст
100% гарантии, но на основные ошибки укажет.


## <a href="#maintaining" class="anchor" id="maintaining"><span class="octicon octicon-link"></span></a>Сопровождение пакетов

Если вы сопровождаете пакет и хотите его обновить, просто загрузите обновленный
пакет еще раз. Читайте - и, по возможности, отвечайте - комментарии к вашему
пакету, там иногда могут быть очень полезные замечания или дельные предложения.
Если вы не хотите сопровождать больше ваш пакет (или нет времени), то,
пожалуйста, нажмите на кнопку справа (бросить/disown), чтобы те, кто в нем
заинтересован, смогли поддерживать его. Если есть пакет, который не имеет
сопровождающего, и вы хотели бы им стать, вы также можете нажать на
соответствующую кнопку справа в веб-интерфейсе =)

## <a href="#aur-list" class="anchor" id="aur-list"><span class="octicon octicon-link"></span></a>Список рассылки AUR

По любому вопросу, связанному с работой AUR вы всегда можете обратиться в
[список рассылки](//mailman.archlinux.org/mailman/listinfo/aur-general "Список
рассылки") [aur-general (at) archlinux (dot)
org](mailto:aur-general@archlinux.org "email"). На ваш вопрос ответят, вероятно,
достаточно быстро; причем, ответить могут не только обычные пользователи, но и
доверенные пользователи. Также, если вы вдруг неуверены в своем PKGBUILD'е, вы
тоже можете всегда обратиться в список рассылки и показать свой PKGBUILD.

Существует также отдельный список [рассылки для
запросов](//mailman.archlinux.org/mailman/listinfo/aur-requests "Список
рассылки") [aur-requests (at) archlinux (dot)
org](mailto:aur-requests@archlinux.org "email"). На текущий момент (AUR 3.2.0)
общение через данный список рассылки напрямую не рекомендуется - все обычные
запросы должны отсылаться с использованием веб-интерфейса
([подробности](//mailman.archlinux.org/pipermail/aur-general/2014-July/029045.html
"Тред")). Запросы, которые вы можете послать:

* **Удаление пакета**. Запрос должен включать **краткое описание причины**,
почему вы его хотите удалить. Обычные причины - специальный патч, который больше
не нужен; пакет уныл и более не поддерживается апстримом; переименование;
функциональность предоставляется другим пакетом.
* **"Бросить пакет"**. Лишить текущего мейнтейнера права сопровождать данный
пакет. Официальное требование - вы должны связаться до этого с мейнтейнером по
e-mail и **ожидать от него ответа в течение двух недель** (теперь это делается
автоматически при отправке запроса через веб-интерфейс). Однако, если мейнтейнер
неактивен в течение длительного времени, или пакет помечен, как устаревший, в
течение длительного времени, то можно сделать исключение из этого правила.
(Например, если пакет отмечен устаревшим более шести месяцев, то запрос
удовлетворяется автоматически.)
* **Объединение пакетов**. Если пакет подлежит удалению, но имеет голоса (или
важные комментарии), то его можно объединить с другим, который предоставляет то
же самое. Частный случай - это аналогично переименованию пакета из одного в
другой.


Пожалуйста, пишите письма в список рассылки аккуратно. И, желательно, вежливо (а
то потом будете генерировать что-то вроде
[такого](//linux.sytes.net/post/2014/05/aur-driven-by-idiots/ "Блог")) (мы все
знаем, что мы арче-школьники, не надо нас еще раз этим тыкать, мы обидимся).
Также старайтесь избегать избыточного цитирования. И - это практически
требование - предоставляйте ссылки на пакеты. Хороший вариант - составление
списка ссылок в конце письма, а в теле ссылаться на них таким образом `[1]`.
Если не уверены в корректности запроса - посмотрите [архив списка
рассылки](//mailman.archlinux.org/pipermail/aur-requests/ "Список рассылки").


## <a href="#pkgbuild" class="anchor" id="pkgbuild"><span class="octicon octicon-link"></span></a>PKGBUILD

PKGBUILD - это, де-факто, сценарий шелла, указывающий как и почему (в смысле,
зачем) собираться пакету. Он имеет 4 части:

* **Объявление основных переменных**. Об этом я расскажу чуть ниже.
* **Подготовка исходников**. Этот пункт необязательный. Включает в себя
копирование (если вдруг нужно), применение патчей, sed и прочие мелочи. Функция
обозначается, как **prepare()**.
* **Сборка**. Также необязательный пункт. Здесь - и только здесь - должна
проводиться компиляция. Функция обозначается, как **build()**.
* **Установка**. Обязательный пункт. Здесь происходит копирование нужных файлов
в указанный корень (`$pkgdir`). Функция обозначается, как **package()** (для
совмещенных пакетов таких функций несколько и они называются примерно так:
**package_$pkgname()**).

### <a href="#pkgbuild-vars" class="anchor" id="pkgbuild-vars"><span class="octicon octicon-link"></span></a>Переменные PKGBUILD

Основные переменные следующие:

* **pkgbase** - группа пакетов. Например, пакеты `python-pyqt4` и
`python2-pyqt4` имеют одну группу `pyqt4`.
* **pkgname** - имя (или массив имен для совмещенных пакетов) пакета;
обязательная переменная.
* **pkgver** - версия пакета, указанная в апстриме, **pkgrel** -
арче-специфичный релиз пакета.
* **pkgdesc** - краткое описание пакета.
* **arch** - массив архитектур. Как правило, `arch=('i686' 'x86_64')` для
бинарных пакетов (очень-очень редко бывают пакеты, которые предоставляются
только для одной архитектуры) и `arch=('any')` для пакетов, не содержащих
бинарные файлы.
* **url** - адрес апстрима.
* **license** - лицензия. Если лицензия отлична от обычных (распространенные
типы MIT, BSD и custom) - смотри пакет
[core/licenses](//www.archlinux.org/packages/core/any/licenses/ "Пакет
Archlinux") - то ее надо установить вместе с пакетом по пути
`/usr/share/licenses/$pkgname/LICENSE`).
* **depends** - массив зависимостей, **необходимых для работы** пакета.
**optdepends** - это **дополнительные зависимости**, которые не необходимы для
работы, но предоставляют дополнительную функциональность. **makedepends** - это
зависимости, которые не включены в **depends**, но **необходимы при сборке**
пакета. Лучший способ проверить, правильно ли указаны зависимости сборки
(зачастую, это самое важное) - попробуйте собрать пакет в чистом окружении (то
есть совсем совсем чистом). И да, зависимости из группы
[base-devel](//www.archlinux.org/groups/x86_64/base-devel/ "Группа пакетов
Archlinux") указывать не надо.
* Следующие три переменные необязательны. **provides** - список пакетов,
функциональность которых предоставляет данный пакет. **replaces** - список
пакетов, которые данный пакет замещает (обычно используется для решения проблем
с переименованием пакетов при обновлении). **conflicts** - список пакетов, с
которым конфликтует данный пакет (имеет такие же файлы). Пример различия
**provides** и **replaces** - [gvim](//www.archlinux.org/packages/gvim/ "Пакет
Archlinux") предоставляет [vim](//www.archlinux.org/packages/vim/ "Пакет
Archlinux"), а [wireshark-gtk](//www.archlinux.org/packages/wireshark-gtk/
"Пакет Archlinux") замещает wireshark.
* **install** - файл, содержащий сценарии, запускающиеся после
установки/удаления/обновления (смотрите файл `/usr/share/pacman/proto.install`).
* **source** - где брать исходники, файлы предоставляемые вместе с пакетом
указываются только по имени, к данному массиму также прилагается массив хэш сумм
(md5sums/sha1sums/sha256sums/sha384sums/sha512sums).

Все перечисленные выше переменные указываются в заголовке PKGBUILD. К ним также
можно обращаться внутри PKGBUILD'а. Дополнительно стоит упомянуть переменные
**startdir** - директория, откуда запускается makepkg, **srcdir** - директория с
исходниками (`$startdir/src` по умолчанию), **pkgdir** - директория с собранным
пакетом (`$startdir/pkg/$pkgname` по умолчанию). **Не используйте** переменную
**startdir** без крайней необходимости.

### <a href="#pkgbuild-features" class="anchor" id="pkgbuild-features"><span class="octicon octicon-link"></span></a>Некоторые особенности PKGBUILD'ов

К PKGBUILD применимы все правила программирования на шелле. Например, "смешная
шутка":

```bash
pkgdir="/usr pkg"
rm -rf $pkgdir
```

кому-то может показаться не очень смешной, увы. Поэтому все пути (да и вообще
переменные - там где надо, конечно) лучше обрамлять в двойные кавычки
(исключение - условия в двойных квадратных скобках `[[ ... ]]`). Если вы вводите
какие-либо свои переменные, то настоятельно рекоммендуется добавить в начале
подчеркивание `_` во избежание перекрытия переменными makepkg.

В русскоязычном сегменте до сих пор зачастую встречаются строки типа `make ||
return 1`. Дык вот, `return 1` теперь уже давно как не нужен.

Еще можно работать с рядом других переменных, определенных makepkg. Их список
можно глянуть в `/etc/makepkg.conf`. Самые ходовые - флаги компиляции и `CARCH`.
Так, например, если вы собираете пакет, исходники к которому предоставляются в
бинарном виде (проприетарный драйвер, например), то кусок PKGBUILD может
выглядеть так:

```bash
if [ "${CARCH}" == "x86_64" ]; then
  _filearch=amd64
  md5sums=('1f58521c2ddb9195a26a0bb3713a52a6')
else
  _filearch=i386
  md5sums=('ef5a8809b6bff8c9bcf5a28e860a606b')
fi
source=(${pkgname}-${pkgver}.tar.gz:://istodo.ru/distribs/${pkgname}-linux-${pkgver}-${_filearch}.tar.gz)
```

**pkgbase** вообще удобная штука. Например, для создания пакетов одновременно
для двух версий Python PKGBUILD может выглядеть [примерно так]
(//projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/python-biopython
"Archlinux svn"). Или, в общем случае, [как-то так]
(//aur.archlinux.org/packages/ne/netctl-gui/PKGBUILD "AUR").

Вообще говоря, для стандартных случаев существуют прототипы PKGBUILD'ов. Их
можно найти в `/usr/share/pacman/`, хотя местами они могли немного устареть
(больше года как). Так, прототипы для пакетов из системы контроля версий
(git/svn/hg/bzr) однозначно устарели - сейчас используется другой, куда более
аккуратный, формат. Настоятельно рекомендую ознакомиться на эту тему [с данной
статьей](//wiki.archlinux.org/index.php/VCS_PKGBUILD_Guidelines "ArchWiki").
Например, для пакета **qmmp-qsmmp-git** кусок PKGBUILD'а выглядит так:

```bash
pkgname=qmmp-qsmmp-git
_gitname=qsmmp
pkgver=0.5.34.gcd1ca1a
# еще какие-то строки
makedepends=('git')
source=(${_gitname}::git+//gitorious.org/qsmmp/qsmmp.git#branch=qmmp-9999)
md5sums=('SKIP')
pkgver() {
  cd "${_gitname}"
  local ver=`git describe --long`
  printf "%s" "${${ver//-/.}//qmmp./}"
}
```

А для пакета **kdeplasma-applets-stdin-svn** так:

```bash
pkgname=kdeplasma-applets-stdin-svn
pkgver=57
pkgrel=1
_pkgname=plasmoidstdin
_pkgver=0.2
# еще какие-то строки
makedepends=('automoc4' 'cmake' 'subversion')
source=(${_pkgname}::svn+//plasmoidstdin.svn.sourceforge.net/svnroot/${_pkgname}/${_pkgver}/trunk)
md5sums=('SKIP')
pkgver() {
  cd "${srcdir}/${_pkgname}"
  local ver=`svnversion`
  printf "%s" "${ver//[[:alpha:]]}"
}
```

Также, я отмечу, что некоторые пакеты имеют свой устоявшийся формат, поэтому,
зачастую, полезно поискать что-то похожее в AUR и сделать свой PKGBUILD по
образу и подобию.


## <a href="#links" class="anchor" id="links"><span class="octicon octicon-link"></span></a>Дополнительные ссылки

* [Зеркало (git)](//pkgbuild.com/git/aur-mirror.git/ "Зеркало")
* [ArchWiki про AUR](//wiki.archlinux.org/index.php/AUR "ArchWiki")
* [ArchWiki про PKGBUILD](//wiki.archlinux.org/index.php/PKGBUILD "ArchWiki")
* [ArchWiki про makepkg](//wiki.archlinux.org/index.php/Makepkg "ArchWiki")
* [ArchWiki немного про
стандарты](//wiki.archlinux.org/index.php/Arch_packaging_standards "ArchWiki")
(внизу есть весьма полезные ссылки на гайды для конкретных типов пакетов)