Все об Arch Linux
Arch Linux будет тем, что вы из него сделаете!
Все об Arch Linux
Arch Linux будет тем, что вы из него сделаете!
Суть: обновление «по частям» опасно, потому что пакеты в Arch собраны в единую конструкцию. Свежий пакет требует свежие библиотеки, а старые библиотеки не понимают новые пакеты. Обновил glibc, но не пересобрал всё, что от неё зависит, и система превращается в смесь версий, которая разваливается при первом запуске программы. Правильный порядок один: сначала pacman -Syu, потом установка нового пакета.
Arch это rolling release. Пакеты в репозиториях собираются против текущих версий библиотек. Когда ты обновляешь один пакет, а остальные оставляешь старыми, ты создаёшь комбинацию версий, которую никто не тестировал. Именно комбинация, а не сам пакет, чаще всего и ломает систему.
Представь мост. Каждая балка рассчитана на соседние. Замени одну балку на новую, более тяжёлую, и нагрузка перераспределится. Мост может выдержать, а может рухнуть. С пакетами так же: обновление одного элемента меняет требования ко всем остальным. Обновление «по частям» это замена балок по очереди, без расчёта на то, как они сочетаются. Пока меняешь одну, конструкция держится. Меняешь вторую, и где-то появляется трещина.
Официальная документация Arch предупреждает об этом прямо. На странице Partial upgrades написано, что частичные обновления не поддерживаются. Там есть фраза: «Please note that this is only the partial answer». Это не отговорка, а честное признание: предсказать все комбинации версий невозможно, поэтому поддерживается только целое состояние системы.
Пакеты не живут поодиночке. Программа зависит от библиотек, библиотеки зависят от других библиотек. Обновил glibc, и все пакеты, собранные против старой версии, должны обновиться или пересобраться. Обновил openssl, и всё, что с ним работает, ждёт новую версию.
Связь видна в дереве зависимостей. Команда pactree показывает, кто от кого зависит:
pactree glibc # кто зависит от glibc
Вывод огромный, потому что от glibc зависит почти всё. Обновление такой библиотеки тянет за собой сотни пакетов. Если обновить её одну, остальные останутся на старых версиях и начнут падать.
Особенно чувствительны к этому пакеты из AUR. Они собираются на твоей машине против установленных библиотек. Обновилась glibc, а AUR-пакет не пересобран, и он продолжает работать со старой версией, пока не сломается. После крупных обновлений библиотек AUR-пакеты приходится пересобирать вручную, об этом отдельная статья «AUR после крупных библиотек».
При полном обновлении pacman видит всю картину: он знает, что свежий пакет требует новую библиотеку, и обновляет её вместе с ним. При частичном обновлении он видит только один пакет. Библиотека остаётся старой, потому что pacman не считает её устаревшей: базы обновлены, а установленные версии он не проверяет. Рассинхрон копится незаметно, пока однажды свежий пакет не потребует то, чего в системе нет.
Библиотеки в Linux имеют soname: имя с номером версии ABI, например libavcodec.so.61. Программа, собранная против libavcodec.so.61, ищет именно этот файл. Если в системе лежит libavcodec.so.60, запуск падает с ошибкой error while loading shared libraries.
Частичное обновление создаёт ровно эту ситуацию. Ты поставил свежий пакет, собранный против новой библиотеки, а сама библиотека осталась старой. Динамический загрузчик не находит нужный soname, и программа не стартует.
Ошибка error while loading shared libraries выглядит пугающе, но причина почти всегда одна: версия библиотеки не совпадает с той, против которой собран пакет. В Arch это классический симптом частичного обновления. Если такая ошибка появилась после установки одного пакета, первым делом вспомни, когда ты делал pacman -Syu.
Посмотреть soname установленной библиотеки можно так:
readelf -d /usr/lib/libavcodec.so | grep SONAME
Если у свежего пакета в зависимостях указан libavcodec.so.61, а в системе только libavcodec.so.60, pacman при полном обновлении сам подтянет новую библиотеку. При частичном обновлении он этого не сделает, потому что не знает о рассинхроне.
Отдельная история: откат библиотеки вниз. Допустим, обновление glibc что-то сломало, и ты решил вернуть старую версию. Проблема в том, что остальные пакеты уже обновились против новой glibc. Старая версия не содержит новых символов, и программы падают с ошибками вроде undefined symbol.
Откат glibc в одиночку почти всегда ломает систему сильнее. Правильный путь: откатывать не одну библиотеку, а весь набор пакетов, собранных против неё. Как это делается, разобрано в статье «Сломалось после обновления: откат».
Сначала ответь на вопрос: давно ли ты обновлял систему? Если вчера делал pacman -Syu, поставить один пакет можно спокойно:
sudo pacman -Syu # сначала полное обновление
sudo pacman -S vlc # потом установка
Если система не обновлялась неделю, месяц или полгода, порядок тот же, но важность первого шага растёт. pacman -Syu перед установкой закрывает рассинхрон версий. Пропустил его, поставил свежий пакет на старую систему, и получил комбинацию, которую никто не проверял.
Частый вопрос: «Я поставил один пакет без обновления, и всё работает. Это нормально?». Да, пока работает. Поломка случается не в момент установки, а позже, когда свежий пакет начинает тянуть зависимости или когда следующее обновление спотыкается о рассинхрон. Один раз может пройти, привычка заканчивается сломанной системой.
Проверить, что обновления есть, можно без изменения баз:
checkupdates # список обновлений, базы не трогает
Команда из пакета pacman-contrib работает с отдельной копией баз и не создаёт частичное состояние. Тот же список обновлений покажет pacman -Qu. Разница в том, что checkupdates не трогает базы, а pacman -Qu читает уже скачанные. Для быстрой проверки перед установкой хватит любой из них.
Manjaro держит свои репозитории и выпускает обновления пачками, с задержкой относительно Arch. Это осознанная стратегия: пакеты проходят дополнительную проверку, прежде чем попасть к пользователям. Внутри Manjaro обновление тоже должно быть полным, но сама система устроена так, что рассинхрон встречается реже.
Arch работает иначе: пакеты попадают в репозитории сразу после сборки. Никто не держит их неделями. Поэтому правило «только полное обновление» здесь критично. Перенос пакетов из Manjaro в Arch или наоборот ломает систему по той же причине: версии не совпадают. Пакет из Manjaro, поставленный в Arch, собран против других версий библиотек. Он может установиться, но работать не будет. Подробнее в статье «Импорт пакетов из Manjaro».
Иногда пакет хочется не обновлять: свежая версия сломана, фикс ещё не вышел. Легальный способ заморозки есть, и он явный: директива IgnorePkg в /etc/pacman.conf.
# /etc/pacman.conf
[options]
IgnorePkg = linux # не обновлять ядро
Разница между заморозкой и частичным обновлением в осознанности. Частичное обновление это случайность: ты не знаешь, что создаёшь рассинхрон. IgnorePkg это решение: ты знаешь, какой пакет заморожен и почему. Но механика та же, поэтому замораживать можно только «листовые» пакеты: ядро, драйверы, приложения. Библиотеки вроде glibc замораживать нельзя. Подробный разбор в статье «Частичное обновление и IgnorePkg».
Хочешь проверить, как поведёт себя обновление, не рискуя рабочей системой? Заведи тестовую зону: виртуальную машину с Arch. Обновляй её первой, смотри, что ломается, и только потом обновляй основную систему.
# в виртуальной машине
sudo pacman -Syu
Виртуалка не заменит реальное железо: драйверы и модули ядра ведут себя по-разному. Но для библиотек, glibc и системных пакетов она отлично показывает, чего ждать. Как поднять Arch в виртуалке, описано в статье «Arch в виртуальной машине».
Тестовая зона полезна и для AUR. Собери проблемный пакет в виртуалке, посмотри, как он ведёт себя после обновления, и только потом трогай рабочую систему. Если пакет падает в виртуалке, он упадёт и на реальной машине.
Порядок всегда один:
pacman -Syu: полное обновление.И никогда не игнорируй сообщения pacman. Если он пишет про downgrade, version mismatch или local is newer than core, это не шум, а сигнал рассинхрона. Разбор предупреждения в статье «Предупреждение local is newer than core».
Не обязательно. Поломка случается, когда свежий пакет требует библиотеку, которой нет. Если пакет запустился и работает, повезло. Но не закрепляй привычку: следующий раз может не повезти.
Можно, но это частичное обновление. Ядро обновится, а модули и заголовки останутся старыми. DKMS-модули перестанут собираться. Если хочется стабильности, поставь linux-lts и обновляй его как обычно.
По механике да: пакет остаётся старым, остальное обновляется. Разница в осознанности и в том, что замораживают обычно «листовые» пакеты. Библиотеки замораживать нельзя.
Не продолжай установку вслепую. Сначала выполни полное обновление pacman -Syu. Если предупреждение осталось, разберись, какой пакет рассинхронизирован, и откати его.
Виртуальная машина. Arch в VirtualBox или QEMU занимает пару гигабайт и полностью повторяет поведение пакетов. Для проверки обновлений этого достаточно.
Обновление «по частям» опасно, потому что пакеты в Arch связаны между собой. Свежий пакет требует свежие библиотеки, а старые библиотеки не понимают новые пакеты. Правильный порядок один: pacman -Syu, потом установка. Хочешь заморозить пакет, делай это явно через IgnorePkg и только для «листовых» пакетов. Хочешь проверить обновление заранее, используй тестовую зону. И никогда не игнорируй предупреждения pacman о версиях.
Задай вопрос в чате — отвечаем быстро, по делу и без воды.
Комментарии