Сразу к делу: безопаснее всего релизный вариант пакета (pkg) из официального репозитория, а из двух хелперов новичку лучше взять paru. Он ставится из официальных репозиториев Arch, показывает diff PKGBUILD перед сборкой и собирает пакеты в чистом окружении. Варианты pkg-bin и pkg-git — компромиссы: первый ставится быстро, но доверяет чужим бинарникам, второй собирает свежий код из git и может ломаться.
AUR (Arch User Repository) — пользовательский репозиторий Arch. Пакеты в нём не собираются заранее: там лежат PKGBUILD — скрипты, по которым makepkg собирает программу из исходников прямо на твоей машине. Вручную это выглядит так: скачал PKGBUILD, проверил, запустил makepkg, установил получившийся пакет через pacman -U.
AUR-хелпер автоматизирует весь цикл. Он ищет пакет по имени, скачивает PKGBUILD, проверяет зависимости, собирает и ставит. По сути это обёртка над pacman и makepkg с поиском по AUR. Подробный разбор того, как устроен AUR и какие хелперы бывают, — в статье «Какой AUR helper выбрать?».
Главное, что нужно держать в голове: AUR-хелпер не проверяет безопасность PKGBUILD. Он просто выполняет то, что в нём написано. Поэтому выбор хелпера и варианта пакета — вопрос не удобства, а безопасности.
Официальные репозитории Arch проходят проверку: пакеты подписаны, собираются из проверенных исходников и тестируются. AUR устроен иначе. Любой желающий может выложить PKGBUILD, а модераторы проверяют его только на соответствие правилам оформления, а не на безопасность. Вредоносный код в AUR находят уже после того, как кто-то его установил.
yay написан на Go, paru — на Rust. paru начинался как форк в духе yay, поэтому команды у них почти одинаковые, и перейти с одного на другой легко.
Что paru делает лучше:
paru), yay — только из AUR.--cleanbuild), не засоряя домашний каталог.-V для просмотра версии.yay старше и популярнее, поэтому в интернете больше инструкций именно под него. Но по возможностям он не обгоняет paru. Для новой установки разумнее сразу взять paru: он доступен в официальном репозитории, а значит, обновляется вместе с системой и не требует установки хелпера через сам AUR.
В AUR почти у каждого популярного пакета три варианта имени. Разница — в способе получения.
Обычный вариант. Хелпер скачивает PKGBUILD, makepkg собирает программу из исходного кода на твоей машине. Версия — релизная, та, что выложил автор. Сборка занимает время: от пары минут до часа на больших проектах.
Автор выкладывает готовые бинарники, а PKGBUILD просто распаковывает их в систему. Установка занимает секунды, компилятор не нужен. Но твоя машина не участвует в сборке: ты получаешь файлы, собранные кем-то другим, и доверяешь им как есть.
PKGBUILD клонирует репозиторий и собирает самую свежую версию из ветки разработки. Ты получаешь новые фичи раньше всех, но и баги — тоже. Версия меняется при каждом обновлении, и пакет может сломаться в любой момент.
Три причины.
Первая — отсутствие проверки. PKGBUILD в AUR не проходит аудит безопасности. Модераторы следят за оформлением и соответствием правилам, но не разбирают каждую строчку скрипта.
Вторая — права выполнения. makepkg запускает PKGBUILD от имени твоего пользователя. Вредоносный скрипт получит доступ ко всем твоим файлам, ключам и паролям, которые хранятся в системе. Он не сломает систему целиком (для этого нужны права root), но украсть данные — запросто.
Третья — заброшенные пакеты. Многие PKGBUILD годами не обновляются. Автор ушёл, пакет осиротел, а зависимости в системе меняются. Рано или поздно такой пакет перестанет собираться или соберётся с устаревшими, дырявыми зависимостями.
Поэтому в AUR действует правило: ставь только то, что нужно, от проверенных авторов, и всегда смотри, что собираешь.
Релизный pkg. Он собирается из исходников на твоей машине, а исходники можно проверить глазами. Это самый предсказуемый вариант: версия стабильна, зависимости стандартные.
pkg-bin — компромисс. Бинарники собирает автор или CI, и ты не видишь, что внутри. Доверие здесь выше, чем к случайному PKGBUILD, но и риск не нулевой: бинарник может быть собран из другого кода, чем заявлено. Для тяжёлых программ (браузеры, офисные пакеты) это разумный выбор, для мелких утилит — нет смысла.
pkg-git — самый рискованный. Код из ветки разработки не проходит полного тестирования, а PKGBUILD может меняться под каждую новую версию. Ставить такое на рабочую систему не стоит.
Перед установкой загляни на страницу пакета в AUR: количество голосов, комментарии, дата последнего обновления. Пакет с сотней голосов и свежими комментариями — хороший знак. Пакет без голосов, обновлённый три года назад, — повод задуматься.
Критичный момент: AUR-хелпер автоматически подписывает и собирает PKGBUILD. Если в скрипте зашит вредоносный код — например, отправка данных или подмена файлов — он выполнится с правами твоего пользователя. Поэтому главное правило AUR: не ставь пакеты, чей PKGBUILD ты не читал. О том, как отличить честный PKGBUILD от подозрительного, я писал в статье «Как собрать Klavaro из форка: PKGBUILD для личного AUR».
paru и yay показывают diff PKGBUILD перед сборкой. Не пропускай этот шаг: пробегись глазами по скрипту, посмотри, откуда скачиваются исходники и что выполняется в функции build.
Если хочешь посмотреть PKGBUILD без установки, скачай его отдельно:
paru -G имя-пакета # скачать PKGBUILD без сборки
yay -G имя-пакета # то же самое для yay
Затем открой файл и проверь:
source=) — ссылка на официальный репозиторий проекта;sha256sums=) — они должны быть заполнены;build() и package() — там не должно быть ничего, кроме сборки и установки.Если в PKGBUILD есть curl на неизвестный адрес, подмена путей или странные команды в package() — не ставь. Обрати внимание и на переменную pkgver: она должна совпадать с последним релизом проекта. Если автор заморозил версию, а в комментариях жалуются на сломанную сборку, лучше поискать альтернативу. Подробная методика диагностики таких проблем — в статье «Методика решения проблем в Arch Linux».
Команды у обоих хелперов одинаковые, потому что они повторяют синтаксис pacman.
Обновление системы вместе с AUR-пакетами:
paru -Syu
Установка пакета из AUR:
paru -S имя-пакета
Поиск по репозиториям и AUR:
yay -Ss имя-пакета
Удаление пакета с зависимостями и конфигами:
paru -Rns имя-пакета
Поиск осиротевших пакетов (не нужных больше никому):
paru -Qdt
Для сборки в чистом окружении добавь флаг:
paru -S --cleanbuild имя-пакета
Флаг -Syu обновляет и официальные пакеты, и AUR-пакеты за один проход. Если хочешь обновить только AUR — используй paru -Sua.
paru. Он в официальных репозиториях, показывает diff PKGBUILD и собирает в чистом окружении. yay тоже хорош, но его придётся ставить через AUR, а это лишний шаг для первой установки. Если ты уже пользуешься yay и всё работает — менять не обязательно. Разница в безопасности между ними небольшая: оба показывают PKGBUILD перед сборкой. Главное — не сам хелпер, а то, что ты ставишь через него.
Нет. Быстрее — да, безопаснее — нет. Ты получаешь готовые бинарники, собранные кем-то другим, и не можешь проверить, что внутри. Если скорость критична — бери pkg-bin, но только от проверенных авторов. Проверь, как автор собирает бинарники: если в PKGBUILD указан официальный релиз с GitHub с контрольными суммами — это нормально. Если бинарник лежит на файлообменнике — обходи стороной.
На рабочей системе — нет. Версия меняется при каждом обновлении, код из ветки разработки не тестируется. Если очень нужна свежая фича — поставь pkg-git на тестовую машину или в виртуалку.
Частая причина — проблемы с сетью или TLS при обращении к AUR. Разбор типичных ошибок и их лечения — в статье «yay выдаёт EOF при обновлении AUR: дело в IPv6 (gai.conf)» и в свежей статье про ошибки AUR при обновлении. Иногда помогает очистка кеша хелпера или смена зеркала. Начни с простого: перезапусти команду, проверь интернет, посмотри вывод в терминале.
Хотя бы просматривать diff — да. Хелпер показывает изменения перед сборкой. На это уходит десять секунд, а защищает от сюрпризов вроде подмены источника или добавления лишних шагов в сборку. Особенно внимательным будь после долгого перерыва: если пакет не обновлялся полгода, а тут вдруг появилась новая версия — посмотри diff внимательнее.
Безопасность AUR держится на одном правиле: не запускай PKGBUILD, который не читал. Из хелперов бери paru — он в официальных репозиториях и показывает diff перед сборкой. Из вариантов пакета — релизный pkg; pkg-bin оставь для тяжёлых программ, где сборка из исходников слишком долгая, а pkg-git — только для экспериментов. Тогда AUR останется удобным инструментом, а не источником проблем.
Задай вопрос в чате — отвечаем быстро, по делу и без воды.
Комментарии