Все об Arch Linux
Arch Linux будет тем, что вы из него сделаете!
Все об Arch Linux
Arch Linux будет тем, что вы из него сделаете!
Сразу к делу: свой репозиторий в Arch Linux — это обычная папка с собранными пакетами и базой, которую создаёт утилита repo-add. Вся настройка занимает десять минут: создаёшь каталог, кладёшь туда пакеты, запускаешь repo-add, прописываешь репозиторий в /etc/pacman.conf — и pacman ставит твои пакеты как обычные, с зависимостями, обновлениями и удалением. Тебе не нужен сервер и отдельный хостинг: хватит свободного места на диске и пары команд. Ниже разберу каждый шаг и расскажу, как обслуживать репозиторий, чтобы он не превратился в свалку.
Свой репозиторий превращает твои локальные сборки в полноценный источник пакетов, который для pacman ничем не отличается от официального. Он решает три задачи.
Свои собранные пакеты. Ты собираешь пакет через makepkg и получаешь файл .pkg.tar.zst. Вместо того чтобы хранить такие файлы в куче и ставить их вручную через pacman -U, складывай их в репозиторий. Тогда pacman сам найдёт пакет, поставит зависимости и будет видеть обновления. Это особенно удобно, когда пакетов несколько и они зависят друг от друга.
PKGBUILD-ы из AUR для локальной машины или LAN. Собрал пакет из AUR один раз — и ставишь его на все машины в домашней сети без сборки на каждой. Так не приходится гонять makepkg на каждом компьютере и ждать компиляцию. Для LAN-раздачи достаточно одного компьютера с собранными пакетами: остальные машины подключаются к нему по HTTP и получают готовые пакеты без компиляции. Про установку из AUR вручную читай в статье «Установка пакетов из AUR».
Бэкап пакетов. Собранные версии не пропадут при переустановке системы. Список пакетов можно сохранить отдельно, но сами файлы удобнее держать в репозитории: после чистой установки ты просто подключаешь его и ставишь всё одной командой. Такой подход спасает, когда пакет исчез из AUR или его автор перестал обновлять PKGBUILD: собранная версия остаётся у тебя и продолжает работать.
Ещё вариант — импортировать готовые пакеты из других дистрибутивов, например из Manjaro. Как делать это аккуратно и не сломать систему, разобрано в статье «Импорт пакетов из Manjaro».
Создай каталог под репозиторий и положи туда собранный пакет:
mkdir -p /srv/repo # каталог репозитория
cp mypackage-1.0-1-x86_64.pkg.tar.zst /srv/repo/
cd /srv/repo
Каталог можно создать где угодно: в /srv, в домашней папке или на отдельном разделе. Главное — чтобы путь был стабильным, ведь на него ссылается Server в pacman.conf.
Теперь создай базу репозитория:
repo-add myrepo.db.tar.gz mypackage-1.0-1-x86_64.pkg.tar.zst
repo-add создаёт файл myrepo.db.tar.gz — это и есть база репозитория. Заодно появляется симлинк myrepo.db, по которому pacman обращается к базе. Пакет должен лежать в том же каталоге, что и база, иначе repo-add его не найдёт.
Внутри базы лежит сжатый список пакетов с метаданными: имена, версии, зависимости, контрольные суммы. Именно по ней pacman понимает, что доступно в репозитории. Если база повреждена или устарела, пакеты из репозитория перестают находиться.
Добавление нового пакета — та же команда. repo-add дописывает пакет в существующую базу:
repo-add myrepo.db.tar.gz another-package-2.3-1-x86_64.pkg.tar.zst
Если пакет с таким именем уже есть в базе, repo-add заменит запись на новую версию. У repo-add есть пара полезных флагов. -n не создаёт симлинк myrepo.db — пригодится, если раздаёшь базу по HTTP и хочешь держать в каталоге только один файл. --new добавляет пакет, только если его ещё нет в базе, и не трогает существующие записи. Про то, как устроены базы pacman и где они лежат, — в статье «Базы pacman: где лежат».
Открой /etc/pacman.conf и добавь в конец:
[myrepo]
Server = file:///srv/repo
Для репозитория на локальном диске путь указывается через file://. Если репозиторий лежит на другом компьютере в сети, раздай каталог через HTTP (подойдёт python -m http.server или nginx) и укажи адрес:
[myrepo]
Server = http://192.168.1.10/repo
После этого обнови базы:
pacman -Sy
Теперь pacman -S mypackage найдёт пакет в твоём репозитории. Имя секции в pacman.conf должно совпадать с именем базы: секция [myrepo] ищет файл myrepo.db.
Для HTTP-раздачи проверь права на чтение: веб-сервер должен отдавать и базу, и пакеты. Если pacman падает с ошибкой 404, убедись, что файлы лежат в корне раздаваемого каталога, а не во вложенной папке.
Свой репозиторий обычно ставят выше официальных, чтобы перекрывать их версии. Порядок секций в файле имеет значение: pacman ищет пакет в репозиториях сверху вниз и берёт первый найденный. Поэтому, если хочешь перекрыть версию из core или extra, ставь [myrepo] перед ними.
Но помни: смешивать версии из разных репозиториев без полного обновления — прямой путь к частичному обновлению системы. Обновляйся целиком через pacman -Syu, а не точечно, иначе рискуешь получить битые зависимости.
По умолчанию pacman требует подписи от официальных репозиториев. Для своего репозитория на одной машине проще всего ослабить проверку:
[myrepo]
SigLevel = Optional TrustAll
Server = file:///srv/repo
Optional TrustAll означает: подпись проверяется, если она есть, но её отсутствие не блокирует установку. Для локального репозитория этого достаточно. Если подпись не нужна вовсе, можно вообще не трогать SigLevel — pacman примет и подписанные, и неподписанные пакеты.
Для нескольких машин в сети лучше подписать пакеты. Сначала подготовь связку ключей:
pacman-key --init
pacman-key --populate archlinux
Затем подпиши пакеты при добавлении в базу:
repo-add --sign myrepo.db.tar.gz mypackage-1.0-1-x86_64.pkg.tar.zst
repo-add --sign подпишет и пакет, и базу. Подпись создаётся ключом из связки pacman-key. Ключ можно сгенерировать отдельно, но проще использовать pacman-key: так он сразу попадает в доверенные, и pacman не ругается на собственную подпись. На клиентских машинах экспортируй публичный ключ и импортируй его в свою связку, иначе проверка подписи не пройдёт. Там же укажи SigLevel = Required DatabaseOptional. Если pacman ругается на неизвестный ключ, разбор типичной ошибки — в статье «gpg: unknown public key — pacman-key».
Обновление пакета в репозитории — это добавление новой версии через repo-add. Старая запись в базе заменится автоматически:
repo-add myrepo.db.tar.gz mypackage-1.1-1-x86_64.pkg.tar.zst
Удаление пакета из репозитория делает repo-remove:
repo-remove myrepo.db.tar.gz mypackage
Команда repo-remove принимает имя пакета без версии и архитектуры — так удобнее, чем перечислять файлы. После repo-remove пакет исчезает из базы, но файл .pkg.tar.zst остаётся в каталоге. Удали его вручную, если он больше не нужен:
rm /srv/repo/mypackage-1.0-1-x86_64.pkg.tar.zst
На клиентской машине после любых изменений выполни pacman -Sy, чтобы обновить локальную копию базы. Иначе pacman продолжит видеть старые версии и предложит установить прежнюю версию пакета. Если пакет удалён из репозитория, при следующем pacman -Syu он попадёт в список осиротевших — это нормально: репозиторий остаётся источником правды о доступных пакетах.
Главная задача обслуживания — не дать каталогу репозитория превратиться в свалку старых версий. После каждого обновления смотри, что лежит в каталоге:
cd /srv/repo
ls -1 *.pkg.tar.zst
Оставь только последнюю версию каждого пакета, остальное удали. Базу после чистки пересобери с нуля, чтобы в ней не осталось записей про удалённые файлы:
rm myrepo.db.tar.gz
repo-add myrepo.db.tar.gz *.pkg.tar.zst
Такой пересбор базы — самый надёжный способ привести репозиторий в порядок. Проверить целостность базы можно командой pacman -Sy: если pacman не ругается на повреждённый файл, всё в порядке. Ещё полезно следить за свободным местом на диске — база и пакеты растут быстро. Раз в пару месяцев просматривай состав репозитория и убирай пакеты, которые больше не используешь: repo-remove вычистит базу, файлы удали вручную. Так репозиторий остаётся компактным, а pacman -Sy работает быстро. Про автоматическую чистку кеша pacman и старых пакетов читай в статье «Чистка пакетов и кеша: paccache».
Если ты держишь в репозитории несколько AUR-пакетов, собирать каждый вручную утомительно. Простой скрипт делает это за один запуск:
#!/bin/bash
cd /build/aur
for dir in */; do
cd "$dir"
makepkg -f --noconfirm
cp *.pkg.tar.zst /srv/repo/
cd ..
done
repo-add -R /srv/repo/myrepo.db.tar.gz /srv/repo/*.pkg.tar.zst
Флаг -R у repo-add убирает из базы записи, для которых нет файла пакета. Это удобно: старые версии удаляются из базы автоматически, когда ты чистишь каталог.
Запускай скрипт после обновления PKGBUILD-ов, и репозиторий всегда будет свежим. При желании повесь его на cron или systemd-таймер, чтобы сборка шла сама, без твоего участия. Только не забудь обновлять сами PKGBUILD-ы: скрипт собирает то, что лежит на диске, и не проверяет свежесть исходников. Про то, как устроены официальные репозитории и чем они отличаются от твоего, — в статье «Testing-репозитории».
Проверь три вещи. Имя секции в pacman.conf должно совпадать с именем базы. Путь в Server должен указывать на каталог с базой. И не забудь pacman -Sy после изменений — без обновления локальной базы pacman не знает о новых пакетах. Ещё одна частая причина — пакет собран для другой архитектуры. Сверь имя файла с выводом uname -m: x86_64 должно совпадать.
Для одного компьютера — нет. SigLevel = Optional TrustAll отключает обязательную проверку. Если репозиторий лежит на локальном диске и доступен только тебе, угрозы нет. Для репозитория в локальной сети лучше подписать пакеты и ключи, иначе любая машина в сети сможет подменить пакет.
Можно. База одна, а pacman сам выберет пакет подходящей архитектуры. Главное — не клади в один каталог пакеты с одинаковым именем и версией для разных архитектур, иначе repo-add перезапишет запись. Для чистоты удобнее держать отдельные каталоги на каждую архитектуру и подключать их разными секциями в pacman.conf.
testing — официальный репозиторий Arch, куда пакеты попадают перед основными. В нём пакеты лежат временно, пока их проверяют. Свой репозиторий — твой личный: ты сам решаешь, что в него класть и когда обновлять. При этом он спокойно работает рядом с core, extra и multilib — главное, не перекрывать системные пакеты без причины.
Сначала обнови систему целиком — pacman -Syu. Чаще всего сборка падает из-за устаревших зависимостей. Досмотри вывод makepkg до конца: часто причина в конкретной зависимости, которую можно поставить отдельно. Если PKGBUILD сломан, попробуй более старую версию пакета или собери вручную с правками.
Свой репозиторий — это каталог с пакетами и база, которую создаёт repo-add. Десять минут на настройку: mkdir, repo-add, строка в pacman.conf — и pacman работает с твоими пакетами как с обычными. Дальше остаётся обслуживание: чистить старые версии, пересобирать базу и при желании автоматизировать сборку AUR-пакетов скриптом. Для одной машины хватит SigLevel = Optional TrustAll, для сети — подпиши пакеты через repo-add --sign.
Задай вопрос в чате — отвечаем быстро, по делу и без воды.
Комментарии