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

Материал из ALT Linux Wiki
(Новая страница: «Категория:Sisyphus = Usrmerge = '''''Точный план действий сейчас вырабатывается, и его подробности могут измениться.''''' == Введение == Исторически<ref>[http://lists.busybox.net/pipermail/busybox/2010-December/074114.html]</ref> в UNIX System V, а позже и в мейнстримных линукс-дистрибутивах разделяли ката...»)
 
Нет описания правки
Строка 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-совместимых дистрибутивов это типичный подход.
Из двух вариантов, входящих в рамки FHS<ref>[https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf]</ref>, второй лучше хотя бы тем, что уменьшает к-во top-level каталогов, куда упаковывается постоянное содержимое пакетов, до одного. Сейчас среди FHS-совместимых дистрибутивов это типичный подход.


== Rationale ==
== Rationale ==
* Один каталог (пусть с не очень удачным именем <tt>/usr</tt>) как объект манипуляции и как общий носитель фиксированного содержимого пакетов удобнее россыпи каталогов, полный список которых даже невозможно построить. Появляется даже смысл рассматривать его в виде отдельной точки монтирования, которую можно держать общей на многих машинах под общим управлением.
* Один каталог (пусть с не очень удачным именем {{path|/usr}}) как объект манипуляции и как общий носитель фиксированного содержимого пакетов удобнее россыпи каталогов, полный список которых даже невозможно построить. Появляется даже смысл рассматривать его в виде отдельной точки монтирования, которую можно держать общей на многих машинах под общим управлением.
** Один каталог легче снапшотить, по нему легче гонять {{cmd|find}}, ...
** Один каталог легче снапшотить, по нему легче гонять {{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.
* Начиная с версии 255, планируемой к выпуску в течение 2023, {{pkg|systemd}} прекратит поддержку split-usr.
Строка 27: Строка 27:


=== Стадия 1 ===
=== Стадия 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>, если правило нарушено.
* На стадии brp давать <tt>exit 1</tt>, если правило нарушено.
* Переназначить макросы: <tt>%_bindir</tt>, <tt>%_libdir</tt> и другие.
* Переназначить макросы: <tt>%_bindir</tt>, <tt>%_libdir</tt> и другие.


=== Стадия 2 ===
=== Стадия 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 ==
== Incompatibilities ==

Версия от 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