Usrmerge

Usrmerge

Точный план действий сейчас вырабатывается, и его подробности могут измениться. Статус воплощения отслеживается в altbug #46738.

Введение

Исторически в UNIX System V, а позже и в мейнстримных линукс-дистрибутивах разделяли каталоги /bin и /usr/bin, /lib$suff и /usr/lib$suff, и т. п., давая возможность разместить /usr на отдельной файловой системе от /, содержащего все эти подкаталоги.

Позже, с увеличением средних размеров устройств хранения в машинах, сторонники разделения придумали другие обоснования (например, возможность из окружения в /{bin,sbin,libX,...}/ починить немонтирующуюся /usr, но на сегодняшний день непонятно, какой набор утилит и нужных им so/иных файлов стоит признать частью "системы спасения", которая должна быть доступна без /usr, а какой — нет, ибо сами утилиты приобретают универсальный вид и широкие границы применимости. С развитием механизмов initramfs и живых загрузочных/установочных носителей, а также практикой "раздела восстановления" на локальном хранилище машины среди настольных дистрибутивов этот аргумент теряет всякий смысл.

Чем сохранять бесцельно дублирующие друг друга два класса мест для одних и тех же файлов, лучше оставить один из них, а другой устранить:

• либо переложить /usr/{bin,sbin,lib,libx32,lib64,libexec,local,share,src,...} в корень,
• либо поместить аналоги этих каталогов из / в /usr.

Из двух вариантов, входящих в рамки FHS, второй лучше хотя бы тем, что уменьшает к-во top-level каталогов, куда упаковывается постоянное содержимое пакетов, до одного. Сейчас среди FHS-совместимых дистрибутивов это типичный подход.

Rationale

• Один каталог (пусть с не очень удачным именем /usr) как объект манипуляции и как общий носитель фиксированного содержимого пакетов удобнее россыпи каталогов, полный список которых даже невозможно построить. Появляется даже смысл рассматривать его в виде отдельной точки монтирования, которую можно держать общей на многих машинах под общим управлением.
  • Один каталог легче снапшотить, по нему легче гонять find, ...
• Упаковка всего пакетного содержимого в /usr открывает дорогу к техническому /, который не находится на устройстве хранения и содержит только пустые каталоги-точки-монтирования.
• Возникает осмысленное разделение между /usr, /var и /etc: первый каталог несёт в себе постоянное содержимое пакетов, не предназначенное к ручной модификации (не через пакетную систему или доставку образа), а другие два уже исторически применяются для переменного хранимого состояния и общесистемных конфигов.
• Сборочным скриптам и прочим интеграционным программным компонентам не нужно будет перебирать каталоги, в которых находится искомая программа.
• Начиная с версии 255, планируемой к выпуску в течение 2023, systemd прекратит поддержку split-usr и unmerged-usr; вот коммит.
  • Из кода проекта systemd, помимо прочего, исчезнут все упоминания старых каталогов; например, директива ProtectKernelModules= больше не будет монтировать заглушку поверх /lib/modules, и т. п.

Proposed changes

Необходимые действия можно разбить на две стадии.

Стадия 1

• Научить rpm автогенерировать симлинки на файлы /{bin,lib,...}/x => /usr/{bin,lib,...}/x, если в пакете указано Provides: /bin/x и упакован файл /usr/bin/x, и т. д.
• Переназначить макросы: %_bindir, %_libdir и другие.
• На стадии brp завершаться с ошибкой, если обнаружены разные файлы в /bin/x и /usr/bin/x, ...

Стадия 2

Каждая инсталляция перейдёт к ней независимо, как только все пакеты в этой инсталляции будут содержать свои файлы под /usr.

• В пакет filesystem добавить filetrigger, который заменяет /bin с симлинками на симлинк /bin -> /usr/bin.

FAQ

Рекомендуем прочитать другие материалы о преимуществах предлагаемого решения.

Q: А что, если /usr на отдельном разделе по каким-то причинам не примонтируется?

A: Тогда система не сможет загрузиться, как и в случае, если / по каким-то причинам не примонтируется.

Q: А раньше можно было, пользуясь программами в /, починить /usr

A: Несколько тезисов:

• В-нулевых, для того, чтобы возникла такая ситуация, систему должны были установить так, чтобы /usr был отдельным от /, т. е. такая разметка преследовала какую-либо цель.
• Во-первых, для этого нужно, чтобы / смог смонтироваться, а /usr не смог.
• Во-вторых, всё ещё нет критерия, по которому ту или иную программу и её зависимости можно либо отнести к "системе спасения", либо исключить из неё и сослать в /usr.
• В-третьих, нет ни одного задокументированного случая, где таким образом спасли какую-либо типичную GNU/Linux-систему, включая Альт, есть только предание из 1986 года, касавшееся non-Linux тех времён на компьютере тех времён. Рецептов такого восстановления в практически важных случаях, отчуждаемых от компетенций разработчиков ALT и умелых сисадминов, нет тем более. Следовательно, можно заключить, что цитируемая возможность восстановить /usr из / в общем случае является призрачной, и её стоит причислить к религиозным верованиям.
• Несмотря на всё это, нет ничего плохого в том, чтобы рецепт такого спасения (при помощи операционной избыточности инсталляции альта) администратору предложить, но это должен быть явный механизм с минимумом издержек для остальной структуры системы. Есть множество вариантов это реализовать с разными преимуществами и минусами в разных установках; все они out of scope for this document.

User-visible impact

Меньше каталогов верхнего уровня в корне, кроме симлинков.