Все об Arch Linux
Arch Linux будет тем, что вы из него сделаете!
Все об Arch Linux
Arch Linux будет тем, что вы из него сделаете!
Тестовые репозитории Arch работают как полигон для новых версий пакетов: testing, core-testing и extra-testing получают свежие сборки раньше стабильных core и extra. Включать их стоит только тем, кто готов ловить баги, разбираться в зависимостях и сообщать о проблемах мейнтейнерам. Новичкам и рабочим машинам testing противопоказан.
Arch держит два уровня репозиториев. Стабильный уровень это core, extra и multilib. Тестовый уровень это testing, core-testing, extra-testing и multilib-testing.
Поток пакетов выглядит так. Мейнтейнер собирает новую версию и кладёт её в тестовый репозиторий. Там пакет живёт обычно около недели. За это время его ставят пользователи testing, ловят баги, пишут отчёты. Если серьёзных проблем нет, пакет переезжает в стабильный репозиторий.
Разница между тестовыми репозиториями простая:
Когда пакет переходит в стабильный репозиторий, из testing он удаляется. Поэтому testing не накапливает мусор: там всегда только то, что ждёт перехода.
Важный нюанс: testing в конфиге должен стоять выше core и extra. pacman ищет пакет в первом репозитории, где он есть. Если testing выше, свежая версия из testing перекроет стабильную. Посмотреть, что сейчас лежит в testing, можно так:
pacman -Sl testing
Список длинный, поэтому удобнее искать конкретный пакет:
pacman -Sl testing | grep <имя>
Так ты увидишь, есть ли свежая версия в testing и какая у неё версия.
Первая причина: ранний доступ к новым версиям. Ядро, mesa, драйверы, свежие библиотеки появляются в testing раньше, чем в стабильных репозиториях. Кому-то это нужно для работы, кому-то просто интересно посмотреть на новинки.
Вторая причина важнее: обратная связь мейнтейнерам. Arch это rolling release без отдельной команды тестировщиков. Качество стабильных репозиториев держится на том, что часть пользователей ставит testing и сообщает о проблемах. Баг, пойманный в testing, не дойдёт до стабильного репозитория.
Третья причина: проверка на реальном железе. Сборка проходит на машине мейнтейнера, а работает пакет на тысячах разных конфигураций. Видеокарты, Wi-Fi, звук, специфичное железо. Только реальные пользователи могут проверить пакет на таком разнообразии. Чем больше людей тестирует, тем стабильнее становится Arch для всех остальных.
Отчёт о баге с логами и описанием железа помогает мейнтейнеру понять, что пошло не так, ещё до публикации пакета в стабильный репозиторий. Так testing превращается в распределённую команду тестировщиков, которая работает бесплатно и на добровольных началах.
Главный риск: пакеты в testing могут быть сломаны. Это не баг, а особенность процесса. Пакет попал в testing именно потому, что его ещё не проверили как следует.
Конкретные проблемы:
Отдельная история: pacman -Syu с включённым testing обновляет всю систему на тестовые версии. Выборочно поставить «только ядро из testing» не получится. Либо ты живёшь на testing целиком, либо не включаешь его вовсе.
Ещё один риск: обновление ядра из testing. Ядро и модули должны совпадать по версии, а в testing они обновляются независимо. Если поймаешь рассинхрон, загрузка может не пройти, и чинить придётся с live-USB.
Поддержки от мейнтейнеров ждать не стоит. Если пакет из testing сломал систему, ответ будет один: откатывайся или жди фикса. Так устроен процесс, и это нормально.
Открой конфиг pacman:
sudo nano /etc/pacman.conf
Найди секции testing, core-testing и extra-testing. Они закомментированы, то есть начинаются с решётки. Убери решётку перед именем репозитория и перед строкой Include:
[testing]
Include = /etc/pacman.d/mirrorlist
[core-testing]
Include = /etc/pacman.d/mirrorlist
[extra-testing]
Include = /etc/pacman.d/mirrorlist
Секции должны стоять выше своих стабильных собратьев: testing выше core и extra, core-testing выше core, extra-testing выше extra. В стандартном конфиге они уже стоят на нужных местах, так что достаточно просто раскомментировать.
Зеркала для testing те же, что и для стабильных репозиториев: строка Include указывает на /etc/pacman.d/mirrorlist. Отдельные зеркала настраивать не нужно, mirrorlist работает для всех репозиториев сразу.
После правки обнови базы:
sudo pacman -Syy
Флаг -Syy принудительно перекачивает базы, даже если pacman считает их свежими. Без него pacman может не заметить, что список репозиториев изменился.
Проверь, что testing подключился:
pacman -Sl testing | head
Если в выводе есть пакеты, репозиторий работает.
Обновление ничем не отличается от обычного:
sudo pacman -Syu
Разница в том, что теперь -Syu ставит тестовые версии. Каждое обновление это эксперимент: часть пакетов может повести себя неожиданно.
Перед обновлением загляни в ленту новостей на сайте Arch. Там пишут о крупных изменениях и ручных действиях. Для testing это особенно важно: новость может предупреждать о сломанном пакете.
Если обновление зависло или пошло не так, не дёргайся. Разбор ситуации, когда pacman -Syu зависает, есть в статье «Что делать, если pacman -Syu завис».
После обновления проверь целостность подозрительных пакетов:
pacman -Qkk <пакет>
Подробный разбор проверки целостности в статье «Проверка целостности пакетов pacman -Qkk».
Откат делается в два шага. Сначала выключи testing, потом верни пакеты на стабильные версии.
Шаг первый. Закомментируй секции testing, core-testing и extra-testing в /etc/pacman.conf и обнови базы:
sudo nano /etc/pacman.conf
sudo pacman -Syy
Теперь pacman снова видит только стабильные репозитории. Но установленные тестовые пакеты остались на диске. pacman -Syu не понижает версии автоматически, поэтому откатывать придётся вручную.
Шаг второй. Верни пакеты на стабильные версии. Самый быстрый источник старых версий это кэш pacman. Как поставить конкретную версию из кэша, разобрано в статье «Установка конкретной версии из кэша».
Если нужной версии в кэше нет, бери её из архива Arch. Инструкция в статье «Откат пакетов из архива Arch».
Пример. Обновился linux из testing, и система не загрузилась. В кэше лежит предыдущая версия ядра. Ставишь её через pacman -U, и загрузка возвращается. Только не забудь потом откатить linux-headers той же версии, иначе модули не соберутся.
Откатывай не только сам пакет, но и зависимости, которые уехали в testing вместе с ним. Иначе получишь смесь тестовых и стабильных версий, а это худший вариант: система в промежуточном состоянии, и следующее обновление может споткнуться. Про частичные обновления подробнее в статье «Частичное обновление Arch».
Testing для энтузиастов, а не для новичков. Включай его, если:
Не включай testing, если:
Для последнего случая есть альтернатива. Не обязательно включать testing целиком, чтобы попробовать один пакет. Скачай его напрямую с зеркала и поставь через pacman -U:
curl -O https://geo.mirror.pkgbuild.com/testing/os/x86_64/<пакет>.pkg.tar.zst
sudo pacman -U <пакет>.pkg.tar.zst
Так ты тестируешь один пакет, а остальная система остаётся стабильной. Похожий подход работает и с AUR: свежие версии программ можно собрать из AUR, не трогая официальные репозитории.
Если ты всё же решил попробовать testing, начни с тестовой машины или виртуалки. Так ты увидишь, как ведут себя тестовые пакеты, без риска для основной системы. Когда поймёшь, что справляешься с откатами, можно переходить на реальное железо.
testing это общая площадка для кандидатов в core и extra. core-testing и extra-testing разделяют эти потоки: в каждом лежат пакеты только для своего стабильного репозитория. На практике можно включить только core-testing, если интересуют системные пакеты, и не трогать остальное.
Обычно около недели. Точного расписания нет: пакет переезжает в стабильный репозиторий, когда мейнтейнер решает, что он достаточно проверен. Критичный баг может задержать пакет на месяцы, а тривиальное обновление проскочить за пару дней.
Да. Скачай файл пакета с зеркала testing и поставь через pacman -U. Система останется на стабильных версиях, а один пакет будет тестовым. Помни, что его зависимости должны быть совместимы со стабильной системой.
Загрузись с live-USB, откати подозрительные пакеты из кэша или из архива, потом закомментируй testing в pacman.conf. Порядок такой: сначала верни рабочее состояние, потом разбирайся с конфигом.
Можно, но не нужно. Смесь тестовых и стабильных версий это частичное обновление со всеми его проблемами. Либо testing целиком, либо никак.
Testing это инструмент для тех, кто хочет видеть свежие версии раньше всех и готов платить за это стабильностью. Включение занимает минуту: раскомментируй секции в /etc/pacman.conf и выполни pacman -Syy. Дальше каждое обновление это эксперимент, а откат это ручная работа с кэшем и архивом. Если ты не готов к такому, оставь testing выключенным: стабильные core и extra обновляются достаточно быстро, а риск сломать систему не стоит раннего доступа к новым версиям.
Задай вопрос в чате — отвечаем быстро, по делу и без воды.
Комментарии