Usrmerge/HowToTest

Материал из ALT Linux Wiki

Введение

В прошлом веке, на заре линуксостроения, в системах на базе Linux сложилась ситуация, где часть системных файлов, распространяемых в пакетах и не изменяющихся при естественной работе системы, была упакована под /usr/{bin,sbin,lib,lib64,...}, а другая под /{bin,sbin,lib,lib64,...}. Например, /usr/bin/gedit упакован под /usr, программа /sbin/ip для настройки сетевой подсистемы Linux — вне /usr, а программа из того же пакета /usr/sbin/ss — снова внутри. 🤷 Какого-либо чёткого критерия, определяющего, должна ли программа лежать вне или внутри каталога /usr, не существовало; мейнтейнеры принимали решение произвольно. Позднее для сохранения такого произвольного разделения некоторые подводили гипотетические обоснования, не подкреплённые практикой и пользой для администратора, и практика устоялась. Более подробно об этом рассказано на отдельной странице: введение, FAQ.

Никакой пользы в сохранении этого разделения нет (хотя некоторые участники Team высказывали иное мнение, возражения которому изложены на той же странице). С точки зрения как разработчика и мейнтейнера, так и квалифицированного администратора, это разделение имеет смысл убрать, чтобы упростить иерархию системных файлов и исключить возможные внутренние несовместимости, и помещать все неизменяемые файлы в пакетах под /usr. Но, чтобы избавиться от этого технического долга, нужно много сил; подготовка Sisyphus к изменению заняла на момент написания текста более 8 человекомесяцев. По этой причине операцию откладывали, пока могли.

Сейчас, в апреле 2024 года, мы ведём активную подготовку к выпуску одиннадцатой платформы Альт. В течение цикла поддержки репозитория p11 мы планируем, в частности, обновлять пакет systemd, который начиная с версии 255 не поддерживает упаковку, описанную в предыдущем абзаце. Поэтому до выхода p11 нам нужно не только ликвидировать эти дублирующие друг друга пути в Sisyphus, но и организовать аккуратный переезд всех уже установленных систем.

Используемый в системах Альт пакетный менеджер rpm в силу недостатков его реализации сам не справится, и cp -a тоже. В репозиторий выложена специальная программа, которая максимально бережно переносит на место все системные файлы, которые нужно, и заменяет каталоги /{bin,sbin,lib,lib64,...} на ссылки внутрь /usr. Но возможные ошибки в алгоритме переноса способны привести к трудновосстановимой порче программ, библиотек и прочих файлов в системе, поэтому перед тем, как выложить в Сизиф, желательно её протестировать на максимально широком круге инсталляций.

Нас интересуют любые системы на базе Sisyphus, а особенно те, что на базе серверных редакций (где много пакетов с файлами вне /usr), и долгоживущие системы с нестандартным набором пакетов (в отличие от свежеустановленных).

Как помочь тестированию

  • Иметь на руках установленную систему на Сизифе. Обновление с других репозиториев мы собираемся тестировать позднее.
    • Можно, конечно, и систему на p10 таким образом попробовать обновить до Сизифа, но на сегодня (12 апреля 2024) это отлажено гораздо хуже.
  • Рекомендуем воспользоваться средством резервного копирования, например, timeshift, и начать с подготовки снимка текущего состояния системы. Если что-то пойдёт не так, можно будет без потери данных вернуться к снимку.
  • С привилегиями суперпользователя дать следующие команды (рекомендуем скопировать и вставить в терминал):
apt-get remove vim-common
apt-get update && apt-get install usrmerge-hier-convert
(set -x; apt-repo; rpm -qa; apt-repo test 344990) >/tmp/3install.log 2>&1

Удалять vim-common приходится из-за известной баги altbug:49541, которая мешает протестировать миграцию. Если вы полагаетесь в работе на vim, не беда: vim-minimal остаётся, другие текстовые редакторы, в том числе neovim, никак не затронуты. Если vim-common у вас уже отсутствует, ничего удалять не требуется. Начиная с 17 апреля 2024 vim-common не конфликтует с vim-minimal. Если вы при тестировании устанавливаете filesystem версии 3 на более ранней ревизии сизифа, по-прежнему потребуется удалить vim-common.

  • Прислать получившийся файл /tmp/3install.log на почту тому, кто будет это читать, делать выводы и отлаживать процедуру. :)

После этого, если миграция прошла успешно и файл не заканчивается сообщением об ошибке, попробовать получившуюся систему на прочность: сможет ли она успешно перезагрузиться? запускаются ли программы (в уже запущенных шеллах надо дать команду hash -r)? корректно ли работают make-initrd, update-kernel? Вообще проверьте всё, что придёт в голову и касается перемещённых файлов.

Всем, кто откликнется, заранее большое спасибо!