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

## AUR

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

Конечно, вручную скачивать архив с сайта AUR'а, а также проверять обновления, не совсем удобно, поэтому существует набор хелперов. Большинство хелперов представляет собой обертку над pacman. Я выделю только два - packer - минималистичный, удобный, быстрый - и yaourt - на шелле, но зато более функциональный. По не особо понятным мне причинам, в русскоязычном сегменте большее распространение получил yaourt, зарубежом - packer.

Помимо хелперов, существуют также консольные клиенты для работы с AUR. Я выделю, пожалуй, только один - python-aur. Иногда удобная альтернатива веб-интерфейсу.

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

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

- группа - скорее для удобства поиска, сортировки. Немного помогает доверенным пользователям.
- автор, мейнтейнер, последний приславший - люди, кто, соответственно, первый раз прислал данный пакет, сопровождает его в настоящий момент, и последний прислал.
- голоса - когда кому-либо понравился этот пакет или он находит его полезным, он голосует. Теоретически, пакеты, имеющие больше 10 голосов могут попасть в официальные репозитории (если найдется желающий среди доверенных пользователей). Другой путь в официальные репозитории - попасть в список часто используемых, но вы же не пользуетесь pkgstats.

## Установка с AUR

Для работы с AUR требуется установить группу пакетов base-devel. Пакеты с этой группы, как правило, не включены в зависимости. Рекомендуемая установка пакетов с AUR выглядит примерно так:

{% highlight 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 {% endhighlight %}

## Загрузка пакета в AUR

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

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

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

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

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

## Сопровождение пакетов

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

## Список рассылки AUR

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

Существует также отдельный список рассылки для запросов aur-requests (at) archlinux (dot) org. На текущий момент (AUR 3.2.0) общение через данный список рассылки напрямую не рекомендуется - все обычные запросы должны отсылаться с использованием веб-интерфейса (подробности). Запросы, которые вы можете послать:

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

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

## PKGBUILD

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

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

### Переменные 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 - то ее надо установить вместе с пакетом по пути `/usr/share/licenses/$pkgname/LICENSE`).
- depends - массив зависимостей, необходимых для работы пакета. optdepends - это дополнительные зависимости, которые не необходимы для работы, но предоставляют дополнительную функциональность. makedepends - это зависимости, которые не включены в depends, но необходимы при сборке пакета.
  Лучший способ проверить, правильно ли указаны зависимости сборки (зачастую, это самое важное) - попробуйте собрать пакет в чистом окружении (то есть совсем совсем чистом). И да, зависимости из группы base-devel указывать не надо.
- Следующие три переменные необязательны. provides - список пакетов, функциональность которых предоставляет данный пакет. replaces - список пакетов, которые данный пакет замещает (обычно используется для решения проблем с переименованием пакетов при обновлении). conflicts - список пакетов, с которым конфликтует данный пакет (имеет такие же файлы).
  Пример различия provides и replaces - gvim предоставляет vim, а wireshark-gtk замещает 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 без крайней необходимости.

### Некоторые особенности PKGBUILD'ов

К PKGBUILD применимы все правила программирования на шелле. Например, "смешная шутка": {% highlight bash %} pkgdir="/usr pkg" rm -rf $pkgdir {% endhighlight %} кому-то может показаться не очень смешной, увы. Поэтому все пути (да и вообще переменные - там где надо, конечно) лучше обрамлять в двойные кавычки (исключение - условия в двойных квадратных скобках `[[ ... ]]`). Если вы вводите какие-либо свои переменные, то настоятельно рекоммендуется добавить в начале подчеркивание `_` во избежание перекрытия переменными makepkg.

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

Еще можно работать с рядом других переменных, определенных makepkg. Их список можно глянуть в `/etc/makepkg.conf`. Самые ходовые - флаги компиляции и `CARCH`. Так, например, если вы собираете пакет, исходники к которому предоставляются в бинарном виде (проприетарный драйвер, например), то кусок PKGBUILD может выглядеть так: {% highlight 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) {% endhighlight %}

pkgbase вообще удобная штука. Например, для создания пакетов одновременно для двух версий Python PKGBUILD может выглядеть примерно так. Или, в общем случае, как-то так.

Вообще говоря, для стандартных случаев существуют прототипы PKGBUILD'ов. Их можно найти в `/usr/share/pacman/`, хотя местами они могли немного устареть (больше года как). Так, прототипы для пакетов из системы контроля версий (git/svn/hg/bzr) однозначно устарели - сейчас используется другой, куда более аккуратный, формат. Настоятельно рекомендую ознакомиться на эту тему с данной статьей. Например, для пакета qmmp-qsmmp-git кусок PKGBUILD'а выглядит так: {% highlight 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./}" } {% endhighlight %} А для пакета kdeplasma-applets-stdin-svn так: {% highlight 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:]]}" } {% endhighlight %} Также, я отмечу, что некоторые пакеты имеют свой устоявшийся формат, поэтому, зачастую, полезно поискать что-то похожее в AUR и сделать свой PKGBUILD по образу и подобию.

## Дополнительные ссылки

- Зеркало (git)
- ArchWiki про AUR
- ArchWiki про PKGBUILD
- ArchWiki про makepkg
- ArchWiki немного про стандарты (внизу есть весьма полезные ссылки на гайды для конкретных типов пакетов)