add paper

small changes in css
This commit is contained in:
arcan1s 2014-06-23 04:47:19 +04:00
parent 8a0446c893
commit cc462bc930
2 changed files with 180 additions and 3 deletions

View File

@ -50,10 +50,9 @@
body {
padding: 50px;
font: 14px/1.5 "Liberation Serif", Lato, "Helvetica Neue", Helvetica, Arial, sans-serif;
font: 14px/1.5 "Liberation Serif", Helvetica, Arial, sans-serif;
color: #555555;
font-weight: 300;
background: #dcdcdc
background: #eaeaea
}
h1, h2, h3, h4, h5, h6 {
@ -63,6 +62,7 @@ h1, h2, h3, h4, h5, h6 {
p, ul, ol, table, pre, dl {
margin: 0 0 20px;
text-align: justify;
}
h1, h2, h3 {

View File

@ -0,0 +1,177 @@
---
category: ru
type: paper
layout: paper
tags: archlinux
title: Немного об Arch User Repository
short: about-aur
description: Статья посвященная работе с пользовательским репозиторием Archlinux. Постарался сделать акцент на сопровождении пакетов. Данная статья, в большей степени, представляет собой компиляцию нескольких англоязычных статей Wiki и немного личного опыта. Поэтому не уверен, что в данной статье на английском языке будет толк.
---
<h2><a name="aur" class="anchor" href="#aur"><span class="octicon octicon-link"></span></a>AUR</h2>
<p align="justify">Итак, <a href="https://aur.archlinux.org/">Arch User Repository</a> (AUR или АУР) - это репозиторий, поддерживаемый и развиваемый практически исключительно сообществом Archlinux. Есть еще отдельные люди, называемые <a href="https://www.archlinux.org/trustedusers/">доверенными пользователями</a> (TU), на плечах которых лежит своеобразная "модерация" этого репозитория. На мой скромный взгляд, едва ли не единственное отличие Archlinux от других дистрибутивов - это наличие AUR'а. Отличие этого репозитория от обычных прежде всего в том, что он <b>не содержит</b> архивов с исходниками или собранных пакетов - только скрипт сборки (PKGBUILD) и, возможно, дополнительные текстовые файлы.</p>
<p align="justify">Конечно, вручную скачивать архив с сайта AUR'а, а также проверять обновления, не совсем удобно, поэтому существует <a href="https://wiki.archlinux.org/index.php/AUR_Helpers">набор хелперов</a>. Большинство хелперов представляет собой обертку над pacman. Я выделю только два - <a href="https://aur.archlinux.org/packages/packer/">packer</a> - минималистичный, удобный, быстрый - и <a href="https://aur.archlinux.org/packages/yaourt/">yaourt</a> - на шелле, но зато более функциональный. По не особо понятным мне причинам, в русскоязычном сегменте большее распространение получил yaourt, зарубежом - packer.</p>
<p align="justify">Помимо хелперов, существуют также консольные клиенты для работы с AUR. Я выделю, пожалуй, только один - <a href="https://aur.archlinux.org/packages/python3-aur/">python-aur</a>. Иногда удобная альтернатива веб-интерфейсу.</p>
<p align="justify">Другая особенность данного репозитория - и не менее важная - <b>все действия с ним осуществляются на свой страх и риск</b>. Опасные и некорректные пакеты, конечно же, удаляются, но вполне могут быть и ошибки при сборке и еще все, что сможете придумать. Дык вот - работа с ним на вашей совести, и никто вам ничем не обязан, если что-то сломается. По этой же причине, ни один хелпер в обозримом будущем не будет перенесен в официальные репозитории.</p>
<p align="justify">У пакетов в AUR есть несколько характеристик, которых нет у пакетов в официальных репозиториях:
<ul>
<li>группа - скорее для удобства поиска, сортировки. Немного помогает доверенным пользователям.</li>
<li>автор, мейнтейнер, последний приславший - люди, кто, соответственно, первый раз прислал данный пакет, сопровождает его в настоящий момент, и последний прислал.</li>
<li>голоса - когда кому-либо понравился этот пакет или он находит его полезным, он голосует. Теоретически, пакеты, имеющие больше 10 голосов могут попасть в официальные репозитории (если найдется желающий среди доверенных пользователей). Другой путь в официальные репозитории - попасть в <a href="https://www.archlinux.de/?page=PackageStatistics">список часто используемых</a>, но вы же не пользуетесь <a href="https://www.archlinux.org/packages/pkgstats">pkgstats</a>.</li>
</ul>
</p>
<h2><a name="install-from-aur" class="anchor" href="#install-from-aur"><span class="octicon octicon-link"></span></a>Установка с AUR</h2>
<p align="justify">Для работы с AUR требуется установить группу пакетов <a href="https://www.archlinux.org/groups/x86_64/base-devel/">base-devel</a>. Пакеты с этой группы, как правило, <b>не включены</b> в зависимости. Рекомендуемая установка пакетов с AUR выглядит примерно так:</p>
{% highlight bash %}
# скачать архив с PKGBUILD'ом c AUR
curl -L -O https://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 name="upload-to-aur" class="anchor" href="#upload-to-aur"><span class="octicon octicon-link"></span></a>Загрузка пакета в AUR</h2>
<p align="justify"><b>Никаких</b> <code>makepkg -S</code>. С недавних пор данный метод считается устаревшим. Но обо всем по-порядку</p>
<p align="justify">Нам нужно загрузить архив на сайт. В этом архиве <b>должны быть</b> PKGBUILD и .AURINFO. По поводу первого я расскажу еще чуть ниже, второй генерируется автоматически. Также, там могут быть установочные скрипты (*.install), патчи, файлы лицензии (если не предоставляются апстримом с исходниками), сервисы systemd, скрипты запуска - это то, что обычно включено. <b>Никаких исходников</b>. И тем более <b>никаких бинарников</b>. (Шутки-шутками, а я помню пакет, в котором исходный код записывался с помощью <code>cat << EOF</code> прямо в тексте PKGBUILD'а.)</p>
<p align="justify">Все файлы кладем в одну директорию. Убедились, что install файл, если он есть, указан в переменной install, все другие исходные файлы указаны в массиве source, а хэш-суммы правильные (их легко можно сгенерировать, набрав <code>makepkg -g</code>). Далее из этой директории запустить команду <code>mkaurball</code> (пакет <a href="https://www.archlinux.org/packages/pkgbuild-introspection">pkgbuild-introspection</a>) - и архив готов.</p>
<p align="justify">Несколько правил загрузки пакета в AUR:
<ul>
<li>Если такой пакет существует в официальном репозитории (любой версии), то <b>не нужно</b> заливать новый пакет. Если репозиторный пакет устарел, просто пометьте его, как устаревший. Исключение из этого правила составляют пакеты из системы контрля версий (VCS), о них чуть ниже.</li>
<li>Проверьте AUR. Если такой пакет уже существует и у него есть мейнтейнер, вы <b>не сможете залить</b> свой пакет. Если у него нет мейнтейнера, то вы автоматически будете его сопровождающим после обновления. Еще может быть такой же пакет, но с другим названием, будьте внимательны.</li>
<li>PKGBUILD должен следовать (более-менее) стандартам и должен быть более-менее аккуратным. В противном случае, пакет может быть удален без предупреждения.</li>
<li>Пакет должен быть полезен еще кому-либо кроме Вас =)</li>
<li>Рекомендуется проверить <b>собранный пакет и PKGBUILD</b> с помощью <a href="https://www.archlinux.org/packages/namcap">namcap</a>. Это не даст 100% гарантии, но на основные ошибки укажет.</li>
</ul>
</p>
<h2><a name="maintaining" class="anchor" href="#maintaining"><span class="octicon octicon-link"></span></a>Сопровождение пакетов</h2>
<p align="justify">Если вы сопровождаете пакет и хотите его обновить, просто загрузите обновленный пакет еще раз. Читайте - и, по возможности, отвечайте - комментарии к вашему пакету, там иногда могут быть очень полезные замечания или дельные предложения. Если вы не хотите сопровождать больше ваш пакет (или нет времени), то, пожалуйста, нажмите на кнопку справа (бросить/disown), чтобы те, кто в нем заинтересован, смогли поддерживать его. Если есть пакет, который не имеет сопровождающего, и вы хотели бы им стать, вы также можете нажать на соответствующую кнопку справа в веб-интерфейсе =)</p>
<h2><a name="aur-list" class="anchor" href="#aur-list"><span class="octicon octicon-link"></span></a>Список рассылки AUR</h2>
<p align="justify">По любому вопросу, связанному с работой AUR вы всегда можете обратиться в <a href="https://mailman.archlinux.org/mailman/listinfo/aur-general">список рассылки</a>. На ваш вопрос ответят, вероятно, достаточно быстро; причем, ответить могут не только обычные пользователи, но и доверенные пользователи. Также, если вы вдруг неуверены в своем PKGBUILD'е, вы тоже можете всегда обратиться в список рассылки и показать свой PKGBUILD.</p>
<p align="justify">Запросы, которые вы можете послать в список рассылки (могут быть совмещены несколько штук в одном письме):
<ul>
<li><b>Удаление пакета</b>. Запрос должен включать <b>краткое описание причины</b>, почему вы его хотите удалить. Обычные причины - специальный патч, который больше не нужен; пакет уныл и более не поддерживается апстримом; переименование; функциональность предоставляется другим пакетом.</li>
<li><b>"Бросить пакет"</b>. Лишить текущего мейнтейнера права сопровождать данный пакет. Официальное требование - вы должны связаться до этого с мейнтейнером по e-mail и <b>ожидать от него ответа в течение двух недель</b>. Если ответа не поступило, то тогда можете слать запрос. Однако, если мейнтейнер неактивен в течение длительного времени, или пакет помечен, как устаревший, в течение длительного времени, то можно сделать исключение из этого правила.</li>
<li><b>Объединение пакетов</b>. Если пакет подлежит удалению, но имеет голоса (или важные комментарии), то его можно объединить с другим, который предоставляет то же самое. Частный случай - это аналогично переименованию пакета из одного в другой.</li>
</ul>
</p>
<p align="justify">Пожалуйста, пишите письма в список рассылки аккуратно. И, желательно, вежливо (а то потом будете генерировать что-то вроде <a href="http://linux.sytes.net/post/2014/05/aur-driven-by-idiots/">такого</a>). Также старайтесь избегать избыточного цитирования. И - это практически требование - предоставляйте ссылки на пакеты. Хороший вариант - составление списка ссылок в конце письма, а в теле ссылаться на них таким образом <code>[1]</code>. Если не уверены в корректности запроса - посмотрите <a href="https://mailman.archlinux.org/pipermail/aur-general/">архив списка рассылки</a>.</p>
<h2><a name="pkgbuild" class="anchor" href="#pkgbuild"><span class="octicon octicon-link"></span></a>PKGBUILD</h2>
<p align="justify">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 name="pkgbuild-vars" class="anchor" href="#pkgbuild-vars"><span class="octicon octicon-link"></span></a>Переменные PKGBUILD</h3>
<p align="justify">Основные переменные следующие:
<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="https://www.archlinux.org/packages/core/any/licenses/">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="https://www.archlinux.org/groups/x86_64/base-devel/">base-devel</a> указывать не надо.</li>
<li>Следующие три переменные необязательны. <b>provides</b> - список пакетов, функциональность которых предоставляет данный пакет. <b>replaces</b> - список пакетов, которые данный пакет замещает (обычно используется для решения проблем с переименованием пакетов при обновлении). <b>conflicts</b> - список пакетов, с которым конфликтует данный пакет (имеет такие же файлы).<br>
Пример различия <b>provides</b> и <b>replaces</b> - <a href="https://www.archlinux.org/packages/gvim/">gvim</a> предоставляет <a href="https://www.archlinux.org/packages/vim/">vim</a>, а <a href="https://www.archlinux.org/packages/wireshark-gtk/">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 align="justify">Все перечисленные выше переменные указываются в заголовке 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 name="pkgbuild-features" class="anchor" href="#pkgbuild-features"><span class="octicon octicon-link"></span></a>Некоторые особенности PKGBUILD'ов</h3>
<p align="justify">К PKGBUILD применимы все правила программирования на шелле. Например, "смешная шутка":
{% highlight bash %}
pkgdir="/usr pkg"
rm -rf $pkgdir
{% endhighlight %}
кому-то может показаться не очень смешной. Поэтому все пути (да и вообще переменные - там где надо, конечно) лучше обрамлять в двойные кавычки (исключение - условия в двойных квадратных скобках <code>[[ ... ]]</code>). Если вы вводите какие-либо свои переменные, то настоятельно рекоммендуется добавить в начале подчеркивание <code>_</code> во избежание перекрытия переменными makepkg.</p>
<p align="justify">В русскоязычном сегменте до сих пор зачастую встречаются строки типа <code>make || return 1</code>. Дык вот, <code>return 1</code> теперь уже давно как не нужен.</p>
<p align="justify">Еще можно работать с рядом других переменных, определенных 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::http://istodo.ru/distribs/${pkgname}-linux-${pkgver}-${_filearch}.tar.gz)
{% endhighlight %}
</p>
<p align="justify"><b>pkgbase</b> вообще удобная штука. Например, для создания пакетов одновременно для двух версий Python PKGBUILD может выглядеть <a href="https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/python-biopython">примерно так</a>. Или, в общем случае, <a href="https://aur.archlinux.org/packages/ne/netctl-gui/PKGBUILD">как-то так</a>.</p>
<p align="justify">Вообще говоря, для стандартных случаев существуют прототипы PKGBUILD'ов. Их можно найти в <code>/usr/share/pacman/</code>, хотя местами они могли немного устареть (больше года как). Так, прототипы для пакетов из системы контроля версий (git/svn/hg/bzr) однозначно устарели - сейчас используется другой, куда более аккуратный, формат. Настоятельно рекомендую ознакомиться на эту тему <a href="https://wiki.archlinux.org/index.php/VCS_PKGBUILD_Guidelines">с данной статьей</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+https://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+https://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 name="links" class="anchor" href="#links"><span class="octicon octicon-link"></span></a>Дополнительные ссылки</h2>
<ul>
<li><a href="http://pkgbuild.com/git/aur-mirror.git/">Зеркало (git)</a></li>
<li><a href="https://wiki.archlinux.org/index.php/AUR">ArchWiki про AUR</a></li>
<li><a href="https://wiki.archlinux.org/index.php/PKGBUILD">ArchWiki про PKGBUILD</a></li>
<li><a href="https://wiki.archlinux.org/index.php/Makepkg">ArchWiki про makepkg</a></li>
<li><a href="https://wiki.archlinux.org/index.php/Arch_packaging_standards">ArchWiki немного про стандарты</a> (внизу есть весьма полезные ссылки на гайды для конкретных типов пакетов)</li>
</ul>