mirror of
https://github.com/arcan1s/arcanis.me.git
synced 2025-04-24 15:27:17 +00:00
187 lines
28 KiB
HTML
187 lines
28 KiB
HTML
---
|
||
category: ru
|
||
type: paper
|
||
hastr: false
|
||
layout: paper
|
||
tags: archlinux
|
||
title: Немного об Arch User Repository
|
||
short: about-aur
|
||
description: Статья посвященная работе с пользовательским репозиторием Archlinux. Постарался сделать акцент на сопровождении пакетов. Данная статья, в большей степени, представляет собой компиляцию нескольких англоязычных статей Wiki и немного личного опыта. Поэтому не уверен, что в данной статье на английском языке будет толк.
|
||
---
|
||
<h2><a href="#aur" class="anchor" id="aur"><span class="octicon octicon-link"></span></a>AUR</h2>
|
||
<p>Итак, <a href="//aur.archlinux.org/" title="AUR">Arch User Repository</a> (AUR или АУР) - это репозиторий, поддерживаемый и развиваемый практически исключительно сообществом Archlinux. Есть еще отдельные люди, называемые <a href="//www.archlinux.org/trustedusers/" title="Доверенные пользователи">доверенными пользователями</a> (TU), на плечах которых лежит своеобразная "модерация" этого репозитория. На мой скромный взгляд, едва ли не единственное отличие Archlinux от других дистрибутивов - это наличие AUR'а. Отличие этого репозитория от обычных прежде всего в том, что он <b>не содержит</b> архивов с исходниками или собранных пакетов - только скрипт сборки (PKGBUILD) и, возможно, дополнительные текстовые файлы.</p>
|
||
|
||
<p>Конечно, вручную скачивать архив с сайта AUR'а, а также проверять обновления, не совсем удобно, поэтому существует <a href="//wiki.archlinux.org/index.php/AUR_Helpers" title="ArchWiki">набор хелперов</a>. Большинство хелперов представляет собой обертку над pacman. Я выделю только два - <a href="//aur.archlinux.org/packages/packer/" title="AUR">packer</a> - минималистичный, удобный, быстрый - и <a href="//aur.archlinux.org/packages/yaourt/" title="AUR">yaourt</a> - на шелле, но зато более функциональный. По не особо понятным мне причинам, в русскоязычном сегменте большее распространение получил yaourt, зарубежом - packer.</p>
|
||
|
||
<p>Помимо хелперов, существуют также консольные клиенты для работы с AUR. Я выделю, пожалуй, только один - <a href="//aur.archlinux.org/packages/python3-aur/" title="AUR">python-aur</a>. Иногда удобная альтернатива веб-интерфейсу.</p>
|
||
|
||
<p>Другая особенность данного репозитория - и не менее важная - <b>все действия с ним осуществляются на свой страх и риск</b>. Опасные и некорректные пакеты, конечно же, удаляются, но вполне могут быть и ошибки при сборке и еще все, что сможете придумать. Дык вот - работа с ним на вашей совести, и никто вам ничем не обязан, если что-то сломается. По этой же причине, ни один хелпер в обозримом будущем не будет перенесен в официальные репозитории.</p>
|
||
|
||
<p>У пакетов в AUR есть несколько характеристик, которых нет у пакетов в официальных репозиториях:
|
||
<ul>
|
||
<li>группа - скорее для удобства поиска, сортировки. Немного помогает доверенным пользователям.</li>
|
||
<li>автор, мейнтейнер, последний приславший - люди, кто, соответственно, первый раз прислал данный пакет, сопровождает его в настоящий момент, и последний прислал.</li>
|
||
<li>голоса - когда кому-либо понравился этот пакет или он находит его полезным, он голосует. Теоретически, пакеты, имеющие больше 10 голосов могут попасть в официальные репозитории (если найдется желающий среди доверенных пользователей). Другой путь в официальные репозитории - попасть в <a href="//www.archlinux.de/?page=PackageStatistics" title="Статистика">список часто используемых</a>, но вы же не пользуетесь <a href="//www.archlinux.org/packages/pkgstats" title="Пакет Archlinux">pkgstats</a>.</li>
|
||
</ul>
|
||
</p>
|
||
|
||
<h2><a href="#install-from-aur" class="anchor" id="install-from-aur"><span class="octicon octicon-link"></span></a>Установка с AUR</h2>
|
||
<p>Для работы с AUR требуется установить группу пакетов <a href="//www.archlinux.org/groups/x86_64/base-devel/" title="Группа пакетов Archlinux">base-devel</a>. Пакеты с этой группы, как правило, <b>не включены</b> в зависимости. Рекомендуемая установка пакетов с AUR выглядит примерно так:</p>
|
||
|
||
{% 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 %}
|
||
|
||
<h2><a href="#upload-to-aur" class="anchor" id="upload-to-aur"><span class="octicon octicon-link"></span></a>Загрузка пакета в AUR</h2>
|
||
<p><b>Никаких</b> <code>makepkg -S</code>. С недавних пор данный метод считается устаревшим. Но обо всем по-порядку</p>
|
||
|
||
<p>Нам нужно загрузить архив на сайт. В этом архиве <b>должны быть</b> PKGBUILD и .AURINFO. По поводу первого я расскажу еще чуть ниже, второй генерируется автоматически. Также, там могут быть установочные скрипты (*.install), патчи, файлы лицензии (если не предоставляются апстримом с исходниками), сервисы systemd, скрипты запуска - это то, что обычно включено. <b>Никаких исходников</b>. И тем более <b>никаких бинарников</b>. (Шутки-шутками, а я помню пакет, в котором исходный код записывался с помощью <code>cat << EOF</code> прямо в тексте PKGBUILD'а.)</p>
|
||
|
||
<p>Все файлы кладем в одну директорию. Убедились, что install файл, если он есть, указан в переменной install, все другие исходные файлы указаны в массиве source, а хэш-суммы правильные (их легко можно сгенерировать, набрав <code>makepkg -g</code>). Далее из этой директории запустить команду <code>mkaurball</code> (пакет <a href="//www.archlinux.org/packages/pkgbuild-introspection" title="Пакет Archlinux">pkgbuild-introspection</a>) - и архив готов.</p>
|
||
|
||
<p>Несколько правил загрузки пакета в AUR:
|
||
<ul>
|
||
<li>Если такой пакет существует в официальном репозитории (любой версии), то <b>не нужно</b> заливать новый пакет. Если репозиторный пакет устарел, просто пометьте его, как устаревший. Исключение из этого правила составляют пакеты из системы контрля версий (VCS), о них чуть ниже.</li>
|
||
<li>Проверьте AUR. Если такой пакет уже существует и у него есть мейнтейнер, вы <b>не сможете залить</b> свой пакет. Если у него нет мейнтейнера, то вы автоматически будете его сопровождающим после обновления. Еще может быть такой же пакет, но с другим названием, будьте внимательны.</li>
|
||
<li>PKGBUILD должен следовать (более-менее) стандартам и должен быть более-менее аккуратным. В противном случае, пакет может быть удален без предупреждения.</li>
|
||
<li>Пакет должен быть полезен еще кому-либо кроме Вас =)</li>
|
||
<li>Рекомендуется проверить <b>собранный пакет и PKGBUILD</b> с помощью <a href="//www.archlinux.org/packages/namcap" title="Пакет Archlinux">namcap</a>. Это не даст 100% гарантии, но на основные ошибки укажет.</li>
|
||
</ul>
|
||
</p>
|
||
|
||
<h2><a href="#maintaining" class="anchor" id="maintaining"><span class="octicon octicon-link"></span></a>Сопровождение пакетов</h2>
|
||
<p>Если вы сопровождаете пакет и хотите его обновить, просто загрузите обновленный пакет еще раз. Читайте - и, по возможности, отвечайте - комментарии к вашему пакету, там иногда могут быть очень полезные замечания или дельные предложения. Если вы не хотите сопровождать больше ваш пакет (или нет времени), то, пожалуйста, нажмите на кнопку справа (бросить/disown), чтобы те, кто в нем заинтересован, смогли поддерживать его. Если есть пакет, который не имеет сопровождающего, и вы хотели бы им стать, вы также можете нажать на соответствующую кнопку справа в веб-интерфейсе =)</p>
|
||
|
||
<h2><a href="#aur-list" class="anchor" id="aur-list"><span class="octicon octicon-link"></span></a>Список рассылки AUR</h2>
|
||
<p>По любому вопросу, связанному с работой AUR вы всегда можете обратиться в <a href="//mailman.archlinux.org/mailman/listinfo/aur-general" title="Список рассылки">список рассылки</a> <a href="mailto:aur-general@archlinux.org" title="email">aur-general (at) archlinux (dot) org</a>. На ваш вопрос ответят, вероятно, достаточно быстро; причем, ответить могут не только обычные пользователи, но и доверенные пользователи. Также, если вы вдруг неуверены в своем PKGBUILD'е, вы тоже можете всегда обратиться в список рассылки и показать свой PKGBUILD.</p>
|
||
|
||
<p>Существует также отдельный список <a href="//mailman.archlinux.org/mailman/listinfo/aur-requests" title="Список рассылки">рассылки для запросов</a> <a href="mailto:aur-requests@archlinux.org" title="email">aur-requests (at) archlinux (dot) org</a>. На текущий момент (AUR 3.2.0) общение через данный список рассылки напрямую не рекомендуется - все обычные запросы должны отсылаться с использованием веб-интерфейса (<a href="//mailman.archlinux.org/pipermail/aur-general/2014-July/029045.html" title="Тред">подробности</a>). Запросы, которые вы можете послать:
|
||
<ul>
|
||
<li><b>Удаление пакета</b>. Запрос должен включать <b>краткое описание причины</b>, почему вы его хотите удалить. Обычные причины - специальный патч, который больше не нужен; пакет уныл и более не поддерживается апстримом; переименование; функциональность предоставляется другим пакетом.</li>
|
||
<li><b>"Бросить пакет"</b>. Лишить текущего мейнтейнера права сопровождать данный пакет. Официальное требование - вы должны связаться до этого с мейнтейнером по e-mail и <b>ожидать от него ответа в течение двух недель</b> (теперь это делается автоматически при отправке запроса через веб-интерфейс). Однако, если мейнтейнер неактивен в течение длительного времени, или пакет помечен, как устаревший, в течение длительного времени, то можно сделать исключение из этого правила. (Например, если пакет отмечен устаревшим более шести месяцев, то запрос удовлетворяется автоматически.)</li>
|
||
<li><b>Объединение пакетов</b>. Если пакет подлежит удалению, но имеет голоса (или важные комментарии), то его можно объединить с другим, который предоставляет то же самое. Частный случай - это аналогично переименованию пакета из одного в другой.</li>
|
||
</ul>
|
||
</p>
|
||
|
||
<p>Пожалуйста, пишите письма в список рассылки аккуратно. И, желательно, вежливо (а то потом будете генерировать что-то вроде <a href="//linux.sytes.net/post/2014/05/aur-driven-by-idiots/" title="Блог">такого</a>) (мы все знаем, что мы арче-школьники, не надо нас еще раз этим тыкать, мы обидимся). Также старайтесь избегать избыточного цитирования. И - это практически требование - предоставляйте ссылки на пакеты. Хороший вариант - составление списка ссылок в конце письма, а в теле ссылаться на них таким образом <code>[1]</code>. Если не уверены в корректности запроса - посмотрите <a href="//mailman.archlinux.org/pipermail/aur-requests/" title="Список рассылки">архив списка рассылки</a>.</p>
|
||
|
||
|
||
<h2><a href="#pkgbuild" class="anchor" id="pkgbuild"><span class="octicon octicon-link"></span></a>PKGBUILD</h2>
|
||
<p>PKGBUILD - это, де-факто, сценарий шелла, указывающий как и почему (в смысле, зачем) собираться пакету. Он имеет 4 части:
|
||
<ul>
|
||
<li><b>Объявление основных переменных</b>. Об этом я расскажу чуть ниже.</li>
|
||
<li><b>Подготовка исходников</b>. Этот пункт необязательный. Включает в себя копирование (если вдруг нужно), применение патчей, sed и прочие мелочи. Функция обозначается, как <b>prepare()</b>.</li>
|
||
<li><b>Сборка</b>. Также необязательный пункт. Здесь - и только здесь - должна проводиться компиляция. Функция обозначается, как <b>build()</b>.</li>
|
||
<li><b>Установка</b>. Обязательный пункт. Здесь происходит копирование нужных файлов в указанный корень (<code>$pkgdir</code>). Функция обозначается, как <b>package()</b> (для совмещенных пакетов таких функций несколько и они называются примерно так: <b>package_$pkgname()</b>).</li>
|
||
</ul>
|
||
</p>
|
||
|
||
<h3><a href="#pkgbuild-vars" class="anchor" id="pkgbuild-vars"><span class="octicon octicon-link"></span></a>Переменные PKGBUILD</h3>
|
||
<p>Основные переменные следующие:
|
||
<ul>
|
||
<li><b>pkgbase</b> - группа пакетов. Например, пакеты <code>python-pyqt4</code> и <code>python2-pyqt4</code> имеют одну группу <code>pyqt4</code>.</li>
|
||
<li><b>pkgname</b> - имя (или массив имен для совмещенных пакетов) пакета; обязательная переменная.</li>
|
||
<li><b>pkgver</b> - версия пакета, указанная в апстриме, <b>pkgrel</b> - арче-специфичный релиз пакета.</li>
|
||
<li><b>pkgdesc</b> - краткое описание пакета.</li>
|
||
<li><b>arch</b> - массив архитектур. Как правило, <code>arch=('i686' 'x86_64')</code> для бинарных пакетов (очень-очень редко бывают пакеты, которые предоставляются только для одной архитектуры) и <code>arch=('any')</code> для пакетов, не содержащих бинарные файлы.</li>
|
||
<li><b>url</b> - адрес апстрима.</li>
|
||
<li><b>license</b> - лицензия. Если лицензия отлична от обычных (распространенные типы MIT, BSD и custom) - смотри пакет <a href="//www.archlinux.org/packages/core/any/licenses/" title="Пакет Archlinux">core/licenses</a> - то ее надо установить вместе с пакетом по пути <code>/usr/share/licenses/$pkgname/LICENSE</code>).</li>
|
||
<li><b>depends</b> - массив зависимостей, <b>необходимых для работы</b> пакета. <b>optdepends</b> - это <b>дополнительные зависимости</b>, которые не необходимы для работы, но предоставляют дополнительную функциональность. <b>makedepends</b> - это зависимости, которые не включены в <b>depends</b>, но <b>необходимы при сборке</b> пакета.<br>
|
||
Лучший способ проверить, правильно ли указаны зависимости сборки (зачастую, это самое важное) - попробуйте собрать пакет в чистом окружении (то есть совсем совсем чистом). И да, зависимости из группы <a href="//www.archlinux.org/groups/x86_64/base-devel/" title="Группа пакетов Archlinux">base-devel</a> указывать не надо.</li>
|
||
<li>Следующие три переменные необязательны. <b>provides</b> - список пакетов, функциональность которых предоставляет данный пакет. <b>replaces</b> - список пакетов, которые данный пакет замещает (обычно используется для решения проблем с переименованием пакетов при обновлении). <b>conflicts</b> - список пакетов, с которым конфликтует данный пакет (имеет такие же файлы).<br>
|
||
Пример различия <b>provides</b> и <b>replaces</b> - <a href="//www.archlinux.org/packages/gvim/" title="Пакет Archlinux">gvim</a> предоставляет <a href="//www.archlinux.org/packages/vim/" title="Пакет Archlinux">vim</a>, а <a href="//www.archlinux.org/packages/wireshark-gtk/" title="Пакет Archlinux">wireshark-gtk</a> замещает wireshark.</li>
|
||
<li><b>install</b> - файл, содержащий сценарии, запускающиеся после установки/удаления/обновления (смотрите файл <code>/usr/share/pacman/proto.install</code>).</li>
|
||
<li><b>source</b> - где брать исходники, файлы предоставляемые вместе с пакетом указываются только по имени, к данному массиму также прилагается массив хэш сумм (md5sums/sha1sums/sha256sums/sha384sums/sha512sums).</li>
|
||
</ul>
|
||
</p>
|
||
|
||
<p>Все перечисленные выше переменные указываются в заголовке PKGBUILD. К ним также можно обращаться внутри PKGBUILD'а. Дополнительно стоит упомянуть переменные <b>startdir</b> - директория, откуда запускается makepkg, <b>srcdir</b> - директория с исходниками (<code>$startdir/src</code> по умолчанию), <b>pkgdir</b> - директория с собранным пакетом (<code>$startdir/pkg/$pkgname</code> по умолчанию). <b>Не используйте</b> переменную <b>startdir</b> без крайней необходимости.</p>
|
||
|
||
<h3><a href="#pkgbuild-features" class="anchor" id="pkgbuild-features"><span class="octicon octicon-link"></span></a>Некоторые особенности PKGBUILD'ов</h3>
|
||
<p>К PKGBUILD применимы все правила программирования на шелле. Например, "смешная шутка":
|
||
|
||
{% highlight bash %}
|
||
pkgdir="/usr pkg"
|
||
rm -rf $pkgdir
|
||
{% endhighlight %}
|
||
|
||
кому-то может показаться не очень смешной, увы. Поэтому все пути (да и вообще переменные - там где надо, конечно) лучше обрамлять в двойные кавычки (исключение - условия в двойных квадратных скобках <code>[[ ... ]]</code>). Если вы вводите какие-либо свои переменные, то настоятельно рекоммендуется добавить в начале подчеркивание <code>_</code> во избежание перекрытия переменными makepkg.</p>
|
||
|
||
<p>В русскоязычном сегменте до сих пор зачастую встречаются строки типа <code>make || return 1</code>. Дык вот, <code>return 1</code> теперь уже давно как не нужен.</p>
|
||
|
||
<p>Еще можно работать с рядом других переменных, определенных makepkg. Их список можно глянуть в <code>/etc/makepkg.conf</code>. Самые ходовые - флаги компиляции и <code>CARCH</code>. Так, например, если вы собираете пакет, исходники к которому предоставляются в бинарном виде (проприетарный драйвер, например), то кусок 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 %}
|
||
|
||
</p>
|
||
|
||
<p><b>pkgbase</b> вообще удобная штука. Например, для создания пакетов одновременно для двух версий Python PKGBUILD может выглядеть <a href="//projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/python-biopython" title="Archlinux svn">примерно так</a>. Или, в общем случае, <a href="//aur.archlinux.org/packages/ne/netctl-gui/PKGBUILD" title="AUR">как-то так</a>.</p>
|
||
|
||
<p>Вообще говоря, для стандартных случаев существуют прототипы PKGBUILD'ов. Их можно найти в <code>/usr/share/pacman/</code>, хотя местами они могли немного устареть (больше года как). Так, прототипы для пакетов из системы контроля версий (git/svn/hg/bzr) однозначно устарели - сейчас используется другой, куда более аккуратный, формат. Настоятельно рекомендую ознакомиться на эту тему <a href="//wiki.archlinux.org/index.php/VCS_PKGBUILD_Guidelines" title="ArchWiki">с данной статьей</a>. Например, для пакета <b>qmmp-qsmmp-git</b> кусок 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 %}
|
||
|
||
А для пакета <b>kdeplasma-applets-stdin-svn</b> так:
|
||
|
||
{% 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 по образу и подобию.
|
||
</p>
|
||
|
||
<h2><a href="#links" class="anchor" id="links"><span class="octicon octicon-link"></span></a>Дополнительные ссылки</h2>
|
||
<ul>
|
||
<li><a href="//pkgbuild.com/git/aur-mirror.git/" title="Зеркало">Зеркало (git)</a></li>
|
||
<li><a href="//wiki.archlinux.org/index.php/AUR" title="ArchWiki">ArchWiki про AUR</a></li>
|
||
<li><a href="//wiki.archlinux.org/index.php/PKGBUILD" title="ArchWiki">ArchWiki про PKGBUILD</a></li>
|
||
<li><a href="//wiki.archlinux.org/index.php/Makepkg" title="ArchWiki">ArchWiki про makepkg</a></li>
|
||
<li><a href="//wiki.archlinux.org/index.php/Arch_packaging_standards" title="ArchWiki">ArchWiki немного про стандарты</a> (внизу есть весьма полезные ссылки на гайды для конкретных типов пакетов)</li>
|
||
</ul>
|