Версия от 16:00, 3 июля 2023

Usrmerge

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

Введение

Исторически^[1] в 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^[2], второй лучше хотя бы тем, что уменьшает к-во top-level каталогов, куда упаковывается постоянное содержимое пакетов, до одного. Сейчас среди FHS-совместимых дистрибутивов это типичный подход.

Rationale

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

Proposed changes

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

Стадия 1

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

Стадия 2

Она наступает на каждой инсталляции независимо, как только все пакеты на ней упаковывают свои файлы под /usr.

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

Incompatibilities

FAQ

Здесь будет секция ЧаВО, как только эти вопросы начнут часто задавать. :) Пока что рекомендуем прочитать другие материалы с описанием преимуществ решения^[3]

Q:

A:

User-visible impact

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

Appendix

[1] [1]

[2] [2]

[3] [3]

[1]

[2]

[3]

@@ Строка 5: / Строка 5: @@
 == Введение ==
-Исторически<ref>[http://lists.busybox.net/pipermail/busybox/2010-December/074114.html]</ref> в UNIX System V, а позже и в мейнстримных линукс-дистрибутивах разделяли каталоги <tt>/bin</tt> и <tt>/usr/bin</tt>, <tt>/lib$suff</tt> и <tt>/usr/lib$suff</tt>, и т. п., давая возможность разместить <tt>/usr</tt> на отдельной файловой системе от <tt>/</tt>, содержащего все эти подкаталоги.
+Исторически<ref>[http://lists.busybox.net/pipermail/busybox/2010-December/074114.html]</ref> в UNIX System V, а позже и в мейнстримных линукс-дистрибутивах разделяли каталоги {{path|/bin}} и {{path|/usr/bin}}, {{path|/lib$suff}} и {{path|/usr/lib$suff}}, и т. п., давая возможность разместить {{path|/usr}} на отдельной файловой системе от {{path|/}}, содержащего все эти подкаталоги.
-Позже, с увеличением средних размеров устройств хранения в машинах, сторонники разделения придумали другие обоснования (например, возможность из окружения в <tt>/{bin,sbin,libX,...}</tt> починить немонтирующуюся <tt>/usr</tt>, но на сегодняшний день непонятно, какой набор утилит и нужных им so/иных файлов стоит признать частью "системы спасения", которая должна быть доступна без <tt>/usr</tt>, а какой — нет, ибо сами утилиты приобретают универсальный вид и широкие границы применимости. С развитием механизмов initramfs и живых загрузочных/установочных носителей, а также практикой "раздела восстановления" на локальном хранилище машины среди настольных дистрибутивов этот аргумент теряет всякий смысл.
+Позже, с увеличением средних размеров устройств хранения в машинах, сторонники разделения придумали другие обоснования (например, возможность из окружения в {{path|/{bin,sbin,libX,...}/}} починить немонтирующуюся {{path|/usr}}, но на сегодняшний день непонятно, какой набор утилит и нужных им so/иных файлов стоит признать частью "системы спасения", которая должна быть доступна без {{path|/usr}}, а какой — нет, ибо сами утилиты приобретают универсальный вид и широкие границы применимости. С развитием механизмов initramfs и живых загрузочных/установочных носителей, а также практикой "раздела восстановления" на локальном хранилище машины среди настольных дистрибутивов этот аргумент теряет всякий смысл.
 Чем сохранять бесцельно дублирующие друг друга два класса мест для одних и тех же файлов, лучше оставить один из них, а другой устранить:
-* либо переложить <tt>/usr/{bin,sbin,lib,libx32,lib64,libexec,local,share,src,...}</tt> в корень,
+* либо переложить {{path|/usr/{bin,sbin,lib,libx32,lib64,libexec,local,share,src,...}}} в корень,
-* либо поместить аналоги этих каталогов из <tt>/</tt> в <tt>/usr</tt>.
+* либо поместить аналоги этих каталогов из {{path|/}} в {{path|/usr}}.
 Из двух вариантов, входящих в рамки FHS<ref>[https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf]</ref>, второй лучше хотя бы тем, что уменьшает к-во top-level каталогов, куда упаковывается постоянное содержимое пакетов, до одного. Сейчас среди FHS-совместимых дистрибутивов это типичный подход.
 == Rationale ==
-* Один каталог (пусть с не очень удачным именем <tt>/usr</tt>) как объект манипуляции и как общий носитель фиксированного содержимого пакетов удобнее россыпи каталогов, полный список которых даже невозможно построить. Появляется даже смысл рассматривать его в виде отдельной точки монтирования, которую можно держать общей на многих машинах под общим управлением.
+* Один каталог (пусть с не очень удачным именем {{path|/usr}}) как объект манипуляции и как общий носитель фиксированного содержимого пакетов удобнее россыпи каталогов, полный список которых даже невозможно построить. Появляется даже смысл рассматривать его в виде отдельной точки монтирования, которую можно держать общей на многих машинах под общим управлением.
 ** Один каталог легче снапшотить, по нему легче гонять {{cmd|find}}, ...
-* Упаковка всего пакетного содержимого в <tt>/usr</tt> открывает дорогу к техническому <tt>/</tt>, который не находится на устройстве хранения и содержит только пустые каталоги-точки-монтирования.
+* Упаковка всего пакетного содержимого в {{path|/usr}} открывает дорогу к техническому {{path|/}}, который не находится на устройстве хранения и содержит только пустые каталоги-точки-монтирования.
-* Возникает осмысленное разделение между <tt>/usr</tt>, <tt>/var</tt> и <tt>/etc</tt>: первый каталог несёт в себе постоянное содержимое пакетов, не предназначенное к ручной модификации (не через пакетную систему или доставку образа), а другие два уже исторически применяются для переменного хранимого состояния и общесистемных конфигов.
+* Возникает осмысленное разделение между {{path|/usr}}, {{path|/var}} и {{path|/etc}}: первый каталог несёт в себе постоянное содержимое пакетов, не предназначенное к ручной модификации (не через пакетную систему или доставку образа), а другие два уже исторически применяются для переменного хранимого состояния и общесистемных конфигов.
 * Сборочным скриптам и прочим интеграционным программным компонентам не нужно будет перебирать каталоги, в которых находится программа.
 * Начиная с версии 255, планируемой к выпуску в течение 2023, {{pkg|systemd}} прекратит поддержку split-usr.
@@ Строка 27: / Строка 27: @@
 === Стадия 1 ===
-* Научить rpm автогенерировать симлинки на файлы <tt>/{bin,lib,...}/x</tt> => <tt>/usr/{bin,lib,...}/x</tt>, если в пакете указано <tt>Provides: /bin/x</tt>.
+* Научить rpm автогенерировать симлинки на файлы {{path|/{bin,lib,...}/x}} => {{path|/usr/{bin,lib,...}/x}}, если в пакете указано <tt>Provides: /bin/x</tt>.
 * На стадии brp давать <tt>exit 1</tt>, если правило нарушено.
 * Переназначить макросы: <tt>%_bindir</tt>, <tt>%_libdir</tt> и другие.
 === Стадия 2 ===
-Она наступает на каждой инсталляции независимо, как только все пакеты на ней упаковывают свои файлы под <tt>/usr</tt>.
+Она наступает на каждой инсталляции независимо, как только все пакеты на ней упаковывают свои файлы под {{path|/usr}}.
-* В пакет <tt>filesystem</tt> добавить filetrigger, который заменяет /bin с симлинками на симлинк /bin -> /usr/bin.
+* В пакет <tt>filesystem</tt> добавить filetrigger, который заменяет {{path|/bin}} с симлинками на симлинк {{path|/bin}} -> {{path|/usr/bin}}.
 == Incompatibilities ==

Usrmerge: различия между версиями