Arch Linux: как я собираю пакеты из AUR и пишу свои PKGBUILD
Сборка пакетов из AUR пугала меня долгое время, и я обходил это хранилище стороной. Штатных пакетов из официальных репозиториев Arch хватало для большинства задач, а всё, что лежало в пользовательском хранилище, казалось чем-то ненадёжным и чужим. Я списывал это на осторожность, хотя на деле это было скорее лень разбираться. Всё изменилось, когда мне понадобился свежий инструмент для работы, которого не было в репозиториях ни с какой стороны. Пришлось нырнуть в AUR с головой. В итоге я не только научился ставить готовые сборки, но и собрал свой первый пакет, написав PKGBUILD с нуля. Расскажу по шагам, как это устроено и с чего начинать, чтобы не наступить на те же грабли.
Почему я долго избегал AUR
Когда я только перешёл на Arch, мне казалось, что правильный путь — только официальные репозитории. Они проверены, подписаны и обновляются мейнтейнерами. AUR же выглядел как Дикий Запад: кто угодно может выложить что угодно, и никакой гарантии, что сборка не сломает систему. Я встречал истории о вирусах в AUR и предпочитал не рисковать.
Проблема была в том, что без AUR не обойтись. Свежие версии многих программ появляются там раньше, чем в репозиториях. Некоторые утилиты вообще живут только в AUR. Рано или поздно каждый пользователь Arch упирается в стену: нужной программы нет, а ждать не хочется. В этот момент выбор простой — либо учиться собирать пакеты, либо сидеть на старой версии.
Что такое AUR и как он устроен
AUR расшифровывается как Arch User Repository. Это хранилище, которое ведёт сообщество, а не команда Arch. В нём лежат не готовые пакеты, а описания сборки — файлы PKGBUILD и сопутствующие материалы вроде патчей и системных юнитов. Сервер, по сути, отдаёт исходный код правил, по которым пакет собирается у тебя на машине.
Такой подход пугает новичков, но зато даёт гибкость. Ты видишь, из чего собирается программа, и можешь поменять параметры под себя. Например, отключить ненужную функцию на этапе configure или добавить свой флаг сборки. В официальных репозиториях такой свободы нет — там пакеты собирают за тебя.
Каждый пакет в AUR имеет страницу на сайте aur.archlinux.org. Там видно описание, версию, количество голосов и комментарии пользователей. Комментарии — полезный источник: если сборка ломается, люди пишут об этом и делятся обходными путями.
Каким AUR-хелпером я пользуюсь и почему
Ставить пакеты из AUR вручную можно, но это быстро надоедает. Для этого и существуют AUR-хелперы — программы, которые автоматизируют поиск, скачивание, сборку и установку. Я перепробовал два самых популярных: yay и paru.
yay хорош тем, что он первым пришёл и стал де-факто стандартом. Он простой и дружелюбный, во многом повторяет синтаксис pacman. Но меня в нём смущала одна деталь: по умолчанию он не показывал содержимое PKGBUILD перед сборкой. Хочешь проверить пакет — приходится вручную смотреть его до установки.
paru мне понравился больше. Он написан на Rust, работает заметно шустрее и, что важнее, по умолчанию показывает PKGBUILD и задаёт вопрос перед каждой сборкой. Эта маленькая привычка — видеть, что именно ты собираешь, — однажды уберегла меня от сомнительной сборки с подозрительными командами в середине файла.
Установка paru несложная. Сначала ставишь зависимость rust-nightly, затем клонируешь репозиторий paru из AUR, собираешь его makepkg и устанавливаешь. После этого обновление системы превращается в одну команду: hелпер обновляет официальные пакеты, а потом по очереди спрашивает про пакеты из AUR.
Как я собираю пакеты из AUR вручную
Прежде чем полностью довериться хелперу, я рекомендую понять, что происходит под капотом, а подробности всегда можно найти в документации Arch Wiki. Каждый пакет из AUR — это папка с файлом PKGBUILD и, возможно, дополнительными файлами. Сборка проходит в несколько шагов, и их легко повторить руками.
Сначала клонируешь репозиторий пакета через git clone по ссылке со страницы AUR. Потом открываешь PKGBUILD и читаешь его от первой до последней строки. Если всё выглядит честно, запускаешь сборку. Собранный пакет появляется в той же папке, и его остаётся установить штатным pacman.
Пара важных деталей, которые я узнал на своей шкуре. Во-первых, makepkg отказывается работать от root — сборка должна идти из-под обычного пользователя. Во-вторых, перед сборкой стоит обновить систему, иначе могут всплыть конфликты версий зависимостей. В-третьих, в конце удобно почистить мусор сборки, чтобы не захламлять домашнюю папку.
Что происходит в момент сборки, я понял не сразу. makepkg скачивает исходники по ссылкам из source, сверяет их с контрольными суммами, распаковывает в рабочую папку и по очереди выполняет функции из PKGBUILD. Компиляция, установка во временный каталог, создание архива пакета — всё это makepkg делает сам. По окончании в папке появляется файл с расширением pkg.tar.zst, который уже ставится штатным pacman. Первый раз я смотрел на этот процесс как на фокус, но на деле он полностью прозрачен и управляем.
Мой первый PKGBUILD
Рано или поздно наступает момент, когда нужной программы нет даже в AUR. Тогда остаётся один путь — написать свой PKGBUILD. Звучит страшно, но на деле это просто текстовый файл с переменными, функциями и инструкциями сборки.
В начале файла указываются базовые переменные: pkgname и pkgver задают имя пакета и версию, pkgrel — номер ревизии сборки, pkgdesc — короткое описание. Дальше идёт arch со списком поддерживаемых архитектур, затем depends и makedepends — зависимости для запуска и для сборки соответственно. Источники перечисляются в source, а контрольные суммы — в sha256sums.
Самая важная часть — функция package. Именно она описывает, какие файлы и куда раскладывать. Если программа собирается стандартным способом, функция короткая: запускается установка с нужным префиксом, и всё. Если сборка сложная, добавляются функции prepare и build, где выполняются подготовка и компиляция.
Мой первый пакет оказался простым. Небольшая утилита собиралась из исходников одной командой, и весь PKGBUILD уместился на экран. Я прописал описание, зависимости и контрольную сумму, после чего makepkg собрal пакет без единой ошибки. Ощущение, когда твой пакет устанавливается командой pacman, незабываемое.
Ошибки, на которых я учился
Без ошибок не обошлось, и часть из них хочу перечислить, чтобы вы их не повторяли. Первая — я забыл указать makedepends. Сборка падала с непонятными ошибками про отсутствующие заголовки, и я потратил вечер, пока не понял, что не хватает библиотеки для компиляции.
Вторая ошибка — контрольная сумма. Я обновил версию пакета, но забыл пересчитать sha256sums. makepkg честно отказался собирать пакет, потому что сумма не совпала. Это, кстати, хорошая защита: если исходник на сервере подменили, сборка просто не начнётся.
Третья ошибка — сборка от root. В первые дни я то и дело пытался запустить makepkg после sudo и получал отказ. Правило простое: makepkg только от обычного пользователя, а установка собранного файла — через sudo pacman.
Безопасность пакетов из AUR
Главный страх новичков — вредоносный пакет. Страх обоснованный, но управляемый. Правило номер один: всегда читать PKGBUILD перед сборкой. В нём видно, какие команды выполняются и откуда качается исходник. Если встречаются подозрительные приёмы вроде скачивания файла с неизвестного сервера и исполнения его на лету — такой пакет лучше пропустить.
Я дополнительно смотрю на несколько вещей. Первая — контрольные суммы, они должны совпадать с официальными. Вторая — дата последнего обновления пакета и поведение автора в комментариях. Третья — количество голосов и отзывы других пользователей. Четыре, если пакет живёт давно и за ним следят, риск существенно ниже.
Ещё один совет — не ставить пакеты из AUR вслепую пачками. Если нужно двадцать пакетов, лучше ставить их по одному и после каждого убедиться, что система работает. Так проще найти виновника, если что-то сломается.
Отдельно про обновления безопасности. Даже в популярных пакетах из AUR иногда замечают нехорошие правки после долгого затишья. Поэтому я не обновляю вслепую и то, что стоит давно. Diff, который показывает хелпер перед обновлением, я просматриваю глазами, даже если это занимает полминуты. Зато я знаю, что моя система не собирает пакет с чужими изменениями, которые туда никто не клал.
Как я ухаживаю за пакетами из AUR
Сборка — это только половина дела. Пакеты из AUR нужно поддерживать: обновлять версии, следить за новыми релизами и вовремя пересобирать. Я делаю это вместе с обновлением всей системы, поэтому процесс стал рутиной.
Раз в несколько дней я запускаю обновление и просматриваю список пакетов из AUR. Если версия отстаёт от официальной, хелпер сам предлагает обновить. Иногда сборка ломается из-за новой версии зависимости — тогда я читаю комментарии на странице пакета, там обычно уже описан фикс.
Отдельно хочу сказать про пакеты, которые я собираю из собственных PKGBUILD. Для них я завёл отдельную папку в домашнем каталоге и держу все файлы в ней. При обновлении просто правлю версию, пересчитываю контрольную сумму и пересобираю. Это занимает минуты, а не часы.
Часть своих маленьких утилит я тоже превратил в пакеты. Раньше скрипты лежали где попало: кто-то в пути, кто-то в домашней папке, и при переезде на новую машину их приходилось вспоминать по одному. Теперь каждая утилита живёт в собственном каталоге с PKGBUILD, и на свежей системе я ставлю их одним списком. Ещё удобнее, что пакет можно подписать и обновлять из одной точки, а не держать копии скриптов в пяти местах. Этот подход заодно дисциплинировал код: утилита, у которой есть PKGBUILD, обязана собираться чисто и иметь понятную структуру файлов.
Итог и чек-лист
Сборка пакетов из AUR перестала казаться магией. Это обычная практика, которая сильно расширяет возможности системы. Я перестал ждать чужие сборки и начал собирать нужное за несколько минут. А умение писать собственные PKGBUILD оказалось полезным даже для своих маленьких утилит: написал скрипт, оформил как пакет — и теперь он ставится одной командой.
Если вы на Arch и боитесь AUR, вот мой чек-лист для старта. Первое — всегда читайте PKGBUILD перед сборкой. Второе — используйте хелпер, который показывает содержимое файла по умолчанию. Третье — проверяйте контрольные суммы и следите за обновлениями. Четвёртое — собирайте пакеты только от обычного пользователя. Пятое — не бойтесь своих первых PKGBUILD, начинайте с простого.
AUR — это не страшная дверь в неизвестность, а удобная мастерская, которая делает Arch по-настоящему гибким. Мой переход на Arch подробно описан в отдельной заметке, а про рутину обновлений и ухода за роллинг-релизом я уже писал раньше. Главное — начать, а дальше всё пойдёт само.