https://www.altlinux.org/api.php?action=feedcontributions&user=ArsenyMaslennikov&feedformat=atomALT Linux Wiki - Вклад [ru]2024-03-28T23:20:52ZВкладMediaWiki 1.38.2https://www.altlinux.org/index.php?title=Usrmerge&diff=78930Usrmerge2024-03-16T10:41:02Z<p>ArsenyMaslennikov: /* Proposed changes */</p>
<hr />
<div>[[Категория:Sisyphus]]<br />
<br />
= Usrmerge =<br />
'''''Точный план действий сейчас вырабатывается, и его подробности могут измениться.'''''<br />
Статус воплощения отслеживается в {{altbug|46738}}.<br />
<br />
== Глоссарий ==<br />
'''{{term|merged-usr}}'''-иерархией называется такая FHS-подобная иерархия каталогов, в которой все неизменяемые при работе файлы из операционной системы (т. е. из состава пакетов в репозитории ОС) помещаются либо внутри префикса ({{path|/usr}}), либо их местоположение является ссылкой внутрь префикса. В такой иерархии {{path|/bin}}, {{path|/lib}} и т. д. будут симлинками на {{path|/usr/bin}}, {{path|/usr/lib}} и т. д. Иерархия, не отвечающая этому правилу (например, та, которую создавал инсталлятор до p11), называется '''{{term|unmerged-usr}}'''.<br />
<br />
'''{{term|split-usr}}'''-конфигурация подразумевает, что исполнимый файл в процессе pid 1 из корневой файловой системы стартует до монтирования {{path|/usr}}, расположенного на отдельном разделе. {{term|split-usr}} не следует путать с {{term|unmerged-usr}}, хоть системы со свойством {{term|split-usr}} и являются подмножеством систем {{term|unmerged-usr}}.<br />
<br />
== Введение ==<br />
Исторически<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|/}}, содержащего все эти подкаталоги.<br />
<br />
Позже, с увеличением средних размеров устройств хранения в машинах, сторонники разделения придумали другие обоснования (например, возможность из окружения в {{path|/{bin,sbin,libX,...}/}} починить немонтирующуюся {{path|/usr}}). Но на сегодняшний день непонятно, какой набор утилит и нужных им so/иных файлов стоит признать частью "системы спасения", которая должна быть доступна без {{path|/usr}}, а какой — нет, ибо сами утилиты приобретают универсальный вид и широкие границы применимости. С развитием механизмов initramfs и живых загрузочных/установочных носителей, а также практикой "раздела восстановления" на локальном хранилище машины среди настольных дистрибутивов этот аргумент теряет всякий смысл.<br />
<br />
Чем сохранять бесцельно дублирующие друг друга два класса мест для одних и тех же файлов, лучше оставить один из них, а другой устранить:<br />
* либо переложить {{path|/usr/{bin,sbin,lib,libx32,lib64,libexec,local,share,src,...}}} в корень,<br />
* либо поместить аналоги этих каталогов из {{path|/}} в {{path|/usr}}.<br />
<br />
Из двух вариантов, входящих в рамки FHS<ref>[https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf]</ref>, второй лучше хотя бы тем, что уменьшает количество top-level каталогов, куда упаковывается постоянное содержимое пакетов, до одного. Сейчас среди FHS-совместимых дистрибутивов это типичный подход, на который в том числе потихоньку начинают полагаться апстримы прикладных пакетов.<br />
<br />
== Rationale ==<br />
* Один каталог (пусть с не очень удачным именем {{path|/usr}}) как объект манипуляции и как общий носитель фиксированного содержимого пакетов удобнее россыпи каталогов, полный список которых даже невозможно построить. Появляется даже смысл рассматривать его в виде отдельной точки монтирования, которую можно держать общей на многих машинах под общим управлением.<br />
** Один каталог легче снапшотить, по нему легче гонять {{cmd|find}}, ...<br />
* Упаковка всего пакетного содержимого в {{path|/usr}} открывает дорогу к виртуальному {{path|/}}, который не находится на устройстве хранения и содержит только пустые каталоги-точки-монтирования.<br />
* Возникает осмысленное разделение между {{path|/usr}}, {{path|/var}} и {{path|/etc}}: первый каталог несёт в себе постоянное содержимое пакетов, не предназначенное к ручной модификации (не через пакетную систему или доставку образа), а другие два уже исторически применяются для переменного хранимого состояния и общесистемных конфигов.<br />
* Сборочным скриптам и прочим интеграционным программным компонентам не нужно будет перебирать каталоги, в которых находится искомая программа.<ref>Вообще-то для этого нужно ещё провести слияние sbin и bin, но оно не несёт срочности и не рассматривается на этой странице.</ref><br />
* Начиная с версии 255, выпущенной в декабре 2023, {{pkg|systemd}} [https://lists.freedesktop.org/archives/systemd-devel/2022-April/047673.html прекратит] поддержку split-usr и unmerged-usr; вот [https://github.com/systemd/systemd/pull/27999/commits/cedcd0bc61913db1e37e19f00d3f97fc72436728 коммит].<br />
** Из кода проекта {{pkg|systemd}}, помимо прочего, исчезнут все упоминания старых каталогов; например, директива <tt>ProtectKernelModules=</tt> больше не будет монтировать заглушку поверх <tt>/lib/modules</tt>, и т. п.<br />
<br />
== Proposed changes ==<br />
Необходимые действия можно разбить на три стадии.<br />
<br />
=== Стадия 1 ===<br />
1) Определить, что слиянию с аналогами внутри /usr подлежат следующие каталоги:<br />
<pre><br />
/bin<br />
/lib<br />
/lib32<br />
/lib64<br />
/libx32<br />
/sbin<br />
</pre><br />
На каждой машине есть некоторые каталоги из этого списка; они и будут перенесены.<br />
<br />
2) Ввести brp-модуль {{term|brp-dupe-bin}}, который на стадии brp завершается с ошибкой, если обнаружены разные файлы в {{path|/bin/x}} и {{path|/usr/bin/x}}, а если один из них есть ссылка на другой, устанавливает две копии такого файла по обоим путям с совпадающими атрибутами и контентом.<br />
Это нужно, чтобы приблизительно 22 пакета могли устанавливаться на все варианты иерархий: и на unmerged-usr, и на merged-usr. Создавать жёсткую ссылку нежелательно: если {{path|/bin/x}} и {{path|/usr/bin/x}} лежат на разных файловых системах, такой пакет туда не установится: RPM не рассечёт жёсткую ссылку на два одинаковых файла.<br />
Большинство пакетов, требующих исправления, достаточно будет просто пересобрать со специальным brp-модулем.<br />
<br />
Некоторые пакеты, например, {{pkg|vim-common}}, сейчас упаковывают разные<br />
файловые объекты в {{path|/bin}} и {{path|/usr/bin}}; другие пакеты ставят файлы прямо<br />
в {{path|%buildroot/bin}}. Их потребуется исправить руками. (Справедливости ради,<br />
многие из них и так понадобится обновить)<br />
<br />
Полный список таких будущих конфликтов на 2024-03-16:<br />
<pre><br />
[('bin/bsh', {'ash', 'bsh'}),<br />
('bin/ksh', {'ksh', 'pdksh'}),<br />
('bin/mail', {'mailutils', 'mailx'}),<br />
('bin/ex', {'vi-traditional', 'vim-common', 'vim-minimal'}),<br />
('bin/rview', {'vim-common', 'vim-minimal'}),<br />
('bin/vi', {'vi-traditional', 'vim-minimal'}),<br />
('sbin/halt', {'shepherd', 'systemd-sysvinit', 'sysvinit'}),<br />
('sbin/reboot', {'shepherd', 'systemd-sysvinit', 'sysvinit'}),<br />
('sbin/shutdown', {'shepherd', 'systemd-sysvinit', 'sysvinit'})]<br />
</pre><br />
Из перечисленных множеств пересекающихся в будущем пакетов многие уже явно конфликтуют друг с другом.<br />
<br />
3) Подготовить пакет {{pkg|filesystem}} версии 3: поместить в нём файлтриггер,<br />
который проверяет, не состоят ли каталоги из списка 1 целиком из<br />
симлинков внутрь {{path|/usr}}, и превращает такой каталог с симлинками в симлинк<br />
на каталог.<br />
Сценарий файлтриггера должен будет давать предельно ясную информацию и<br />
диагностические сообщения на стандартные потоки. Нужно будет либо<br />
положиться на static coreutils, либо очень осторожно обращаться с<br />
обычными и dynamic linker.<br />
<br />
=== Стадия 2 ===<br />
Этот пункт вступает в действие на каждой машине индивидуально при<br />
обновлении её пакетов.<br />
Файлтриггер из пункта 3 обнаруживает, что можно ввести симлинки, и<br />
делает это, завершая процесс usrmerge на данной системе.<br />
<br />
Каждая инсталляция перейдёт к ней независимо, как только все пакеты в этой инсталляции будут содержать свои файлы под {{path|/usr}}.<br />
<br />
=== Стадия 3 ===<br />
Заменить макросы, использующие старые каталоги (<tt>%_udevrulesdir</tt>,<br />
<tt>%_tmpfilesdir</tt> и другие), и пересобрать с ними пакеты, что-либо<br />
помещающие в эти каталоги.<br />
Приближённое число затрагиваемых бинарных пакетов:<br />
<pre><br />
% grep -E '^/(bin|lib[^/]*|sbin)/[a-zA-Z0-9_-]+' contents-index \<br />
| grep -vE '^/lib/(systemd|udev|sysusers.d|modules[^/]*|modprobe.d|security|tmpfiles.d)'<br />
\ # exclude known places<br />
| cut -f2 -d$'\t' | grep -v '^/' # exclude path provides<br />
| sort -u | wc -l<br />
524<br />
</pre><br />
Это оценка по x86_64 + noarch. Исходных, конечно, будет меньше (333).<br />
<br />
При обновлении на эти пакеты будет действовать правило 2, поэтому их<br />
содержимое будет доступно.<br />
<br />
== Incompatibilities ==<br />
<br />
Если корневая файловая система — каскадная композиция на базе, например, overlayfs, и каталоги {{path|/bin}} и подобные находятся ''не в верхнем'' слое стека — автоматически обновить такую корневую файловую систему на {{pkg|filesystem > 3}} '''не выйдет'''. Придётся либо не обновляться, либо пересобрать контейнер/систему на обновлённой пакетной базе.<br />
<br />
== FAQ ==<br />
<br />
Рекомендуем прочитать другие материалы о преимуществах предлагаемого решения<ref>[https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ TheCaseForTheUsrMerge]</ref><ref>[https://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/ separate-usr-is-broken], примеры, где в ранней системе полагаются на наличие {{path|/usr}}}</ref>.<br />
<br />
'''Q: А что, если {{path|/usr}} на отдельном разделе по каким-то причинам не примонтируется?'''<br />
<br />
A: Тогда система не сможет загрузиться, как и в случае, если {{path|/}} по каким-то причинам не примонтируется.<br />
<br />
'''Q: А раньше можно было, пользуясь программами в {{path|/}}, починить {{path|/usr}}'''<br />
<br />
A: Несколько тезисов:<br />
* В-нулевых, для того, чтобы возникла такая ситуация, систему должны были установить так, чтобы {{path|/usr}} был отдельным от {{path|/}}, т. е. такая разметка преследовала какую-либо цель.<br />
* Во-первых, для этого нужно, чтобы {{path|/}} '''смог''' смонтироваться, а {{path|/usr}} '''не смог'''.<br />
* Во-вторых, всё ещё нет критерия, по которому ту или иную программу и её зависимости можно либо отнести к "системе спасения", либо исключить из неё и сослать в {{path|/usr}}.<br />
* В-третьих, нет ни одного задокументированного случая, где таким образом спасли какую-либо типичную GNU/Linux-систему, включая Альт, есть только [https://www.ecb.torontomu.ca/~elf/hack/recovery.html предание] из 1986 года, касавшееся non-Linux тех времён на компьютере тех времён. Рецептов такого восстановления, отчуждаемых от компетенций разработчиков ALT и умелых сисадминов, нет тем более. Следовательно, можно заключить, что в общем случае цитируемая возможность восстановить {{path|/usr}} из {{path|/}} — призрачна.<br />
* Несмотря на всё это, нет ничего плохого в том, чтобы рецепт такого спасения (при помощи операционной избыточности инсталляции альта) администратору ''предложить'', но это должен быть явный механизм с минимумом издержек для остальной структуры системы. Есть множество вариантов это реализовать с разными преимуществами и минусами в разных установках; все они out of scope for this document.<br />
<br />
== User-visible impact ==<br />
Меньше каталогов верхнего уровня в корне, кроме симлинков.<br />
<br />
== Appendix ==</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=Usrmerge&diff=78929Usrmerge2024-03-16T10:36:59Z<p>ArsenyMaslennikov: </p>
<hr />
<div>[[Категория:Sisyphus]]<br />
<br />
= Usrmerge =<br />
'''''Точный план действий сейчас вырабатывается, и его подробности могут измениться.'''''<br />
Статус воплощения отслеживается в {{altbug|46738}}.<br />
<br />
== Глоссарий ==<br />
'''{{term|merged-usr}}'''-иерархией называется такая FHS-подобная иерархия каталогов, в которой все неизменяемые при работе файлы из операционной системы (т. е. из состава пакетов в репозитории ОС) помещаются либо внутри префикса ({{path|/usr}}), либо их местоположение является ссылкой внутрь префикса. В такой иерархии {{path|/bin}}, {{path|/lib}} и т. д. будут симлинками на {{path|/usr/bin}}, {{path|/usr/lib}} и т. д. Иерархия, не отвечающая этому правилу (например, та, которую создавал инсталлятор до p11), называется '''{{term|unmerged-usr}}'''.<br />
<br />
'''{{term|split-usr}}'''-конфигурация подразумевает, что исполнимый файл в процессе pid 1 из корневой файловой системы стартует до монтирования {{path|/usr}}, расположенного на отдельном разделе. {{term|split-usr}} не следует путать с {{term|unmerged-usr}}, хоть системы со свойством {{term|split-usr}} и являются подмножеством систем {{term|unmerged-usr}}.<br />
<br />
== Введение ==<br />
Исторически<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|/}}, содержащего все эти подкаталоги.<br />
<br />
Позже, с увеличением средних размеров устройств хранения в машинах, сторонники разделения придумали другие обоснования (например, возможность из окружения в {{path|/{bin,sbin,libX,...}/}} починить немонтирующуюся {{path|/usr}}). Но на сегодняшний день непонятно, какой набор утилит и нужных им so/иных файлов стоит признать частью "системы спасения", которая должна быть доступна без {{path|/usr}}, а какой — нет, ибо сами утилиты приобретают универсальный вид и широкие границы применимости. С развитием механизмов initramfs и живых загрузочных/установочных носителей, а также практикой "раздела восстановления" на локальном хранилище машины среди настольных дистрибутивов этот аргумент теряет всякий смысл.<br />
<br />
Чем сохранять бесцельно дублирующие друг друга два класса мест для одних и тех же файлов, лучше оставить один из них, а другой устранить:<br />
* либо переложить {{path|/usr/{bin,sbin,lib,libx32,lib64,libexec,local,share,src,...}}} в корень,<br />
* либо поместить аналоги этих каталогов из {{path|/}} в {{path|/usr}}.<br />
<br />
Из двух вариантов, входящих в рамки FHS<ref>[https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf]</ref>, второй лучше хотя бы тем, что уменьшает количество top-level каталогов, куда упаковывается постоянное содержимое пакетов, до одного. Сейчас среди FHS-совместимых дистрибутивов это типичный подход, на который в том числе потихоньку начинают полагаться апстримы прикладных пакетов.<br />
<br />
== Rationale ==<br />
* Один каталог (пусть с не очень удачным именем {{path|/usr}}) как объект манипуляции и как общий носитель фиксированного содержимого пакетов удобнее россыпи каталогов, полный список которых даже невозможно построить. Появляется даже смысл рассматривать его в виде отдельной точки монтирования, которую можно держать общей на многих машинах под общим управлением.<br />
** Один каталог легче снапшотить, по нему легче гонять {{cmd|find}}, ...<br />
* Упаковка всего пакетного содержимого в {{path|/usr}} открывает дорогу к виртуальному {{path|/}}, который не находится на устройстве хранения и содержит только пустые каталоги-точки-монтирования.<br />
* Возникает осмысленное разделение между {{path|/usr}}, {{path|/var}} и {{path|/etc}}: первый каталог несёт в себе постоянное содержимое пакетов, не предназначенное к ручной модификации (не через пакетную систему или доставку образа), а другие два уже исторически применяются для переменного хранимого состояния и общесистемных конфигов.<br />
* Сборочным скриптам и прочим интеграционным программным компонентам не нужно будет перебирать каталоги, в которых находится искомая программа.<ref>Вообще-то для этого нужно ещё провести слияние sbin и bin, но оно не несёт срочности и не рассматривается на этой странице.</ref><br />
* Начиная с версии 255, выпущенной в декабре 2023, {{pkg|systemd}} [https://lists.freedesktop.org/archives/systemd-devel/2022-April/047673.html прекратит] поддержку split-usr и unmerged-usr; вот [https://github.com/systemd/systemd/pull/27999/commits/cedcd0bc61913db1e37e19f00d3f97fc72436728 коммит].<br />
** Из кода проекта {{pkg|systemd}}, помимо прочего, исчезнут все упоминания старых каталогов; например, директива <tt>ProtectKernelModules=</tt> больше не будет монтировать заглушку поверх <tt>/lib/modules</tt>, и т. п.<br />
<br />
== Proposed changes ==<br />
Необходимые действия можно разбить на две стадии.<br />
<br />
=== Стадия 1 ===<br />
1) Определить, что слиянию с аналогами внутри /usr подлежат следующие каталоги:<br />
<pre><br />
/bin<br />
/lib<br />
/lib32<br />
/lib64<br />
/libx32<br />
/sbin<br />
</pre><br />
На каждой машине есть некоторые каталоги из этого списка; они и будут перенесены.<br />
<br />
2) Ввести brp-модуль {{term|brp-dupe-bin}}, который на стадии brp завершается с ошибкой, если обнаружены разные файлы в {{path|/bin/x}} и {{path|/usr/bin/x}}, а если один из них есть ссылка на другой, устанавливает две копии такого файла по обоим путям с совпадающими атрибутами и контентом.<br />
Это нужно, чтобы приблизительно 22 пакета могли устанавливаться на все варианты иерархий: и на unmerged-usr, и на merged-usr. Создавать жёсткую ссылку нежелательно: если {{path|/bin/x}} и {{path|/usr/bin/x}} лежат на разных файловых системах, такой пакет туда не установится: RPM не рассечёт жёсткую ссылку на два одинаковых файла.<br />
Большинство пакетов, требующих исправления, достаточно будет просто пересобрать со специальным brp-модулем.<br />
<br />
3) Подготовить пакет {{pkg|filesystem}} версии 3: поместить в нём файлтриггер,<br />
который проверяет, не состоят ли каталоги из списка 1 целиком из<br />
симлинков внутрь {{path|/usr}}, и превращает такой каталог с симлинками в симлинк<br />
на каталог.<br />
Сценарий файлтриггера должен будет давать предельно ясную информацию и<br />
диагностические сообщения на стандартные потоки. Нужно будет либо<br />
положиться на static coreutils, либо очень осторожно обращаться с<br />
обычными и dynamic linker.<br />
<br />
4) Заменить макросы, использующие старые каталоги (<tt>%_udevrulesdir</tt>,<br />
<tt>%_tmpfilesdir</tt> и другие), и пересобрать с ними пакеты, что-либо<br />
помещающие в эти каталоги.<br />
Приближённое число затрагиваемых бинарных пакетов:<br />
<pre><br />
% grep -E '^/(bin|lib[^/]*|sbin)/[a-zA-Z0-9_-]+' contents-index \<br />
| grep -vE '^/lib/(systemd|udev|sysusers.d|modules[^/]*|modprobe.d|security|tmpfiles.d)'<br />
\ # exclude known places<br />
| cut -f2 -d$'\t' | grep -v '^/' # exclude path provides<br />
| sort -u | wc -l<br />
524<br />
</pre><br />
Это оценка по x86_64 + noarch. Исходных, конечно, будет меньше (333).<br />
<br />
При обновлении на эти пакеты будет действовать правило 2, поэтому их<br />
содержимое будет доступно.<br />
<br />
Некоторые пакеты, например, {{pkg|vim-common}}, сейчас упаковывают разные<br />
файловые объекты в {{path|/bin}} и {{path|/usr/bin}}; другие пакеты ставят файлы прямо<br />
в {{path|%buildroot/bin}}. Их потребуется исправить руками. (Справедливости ради,<br />
многие из них и так понадобится обновить)<br />
<br />
Полный список таких будущих конфликтов на 2024-03-16:<br />
<pre><br />
[('bin/bsh', {'ash', 'bsh'}),<br />
('bin/ksh', {'ksh', 'pdksh'}),<br />
('bin/mail', {'mailutils', 'mailx'}),<br />
('bin/ex', {'vi-traditional', 'vim-common', 'vim-minimal'}),<br />
('bin/rview', {'vim-common', 'vim-minimal'}),<br />
('bin/vi', {'vi-traditional', 'vim-minimal'}),<br />
('sbin/halt', {'shepherd', 'systemd-sysvinit', 'sysvinit'}),<br />
('sbin/reboot', {'shepherd', 'systemd-sysvinit', 'sysvinit'}),<br />
('sbin/shutdown', {'shepherd', 'systemd-sysvinit', 'sysvinit'})]<br />
</pre><br />
Из перечисленных множеств пересекающихся в будущем пакетов многие уже явно конфликтуют друг с другом.<br />
<br />
=== Стадия 2 ===<br />
Этот пункт вступает в действие на каждой машине индивидуально при<br />
обновлении её пакетов.<br />
Файлтриггер из пункта 3 обнаруживает, что можно ввести симлинки, и<br />
делает это, завершая процесс usrmerge на данной системе.<br />
<br />
Каждая инсталляция перейдёт к ней независимо, как только все пакеты в этой инсталляции будут содержать свои файлы под {{path|/usr}}.<br />
<br />
== Incompatibilities ==<br />
<br />
Если корневая файловая система — каскадная композиция на базе, например, overlayfs, и каталоги {{path|/bin}} и подобные находятся ''не в верхнем'' слое стека — автоматически обновить такую корневую файловую систему на {{pkg|filesystem > 3}} '''не выйдет'''. Придётся либо не обновляться, либо пересобрать контейнер/систему на обновлённой пакетной базе.<br />
<br />
== FAQ ==<br />
<br />
Рекомендуем прочитать другие материалы о преимуществах предлагаемого решения<ref>[https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ TheCaseForTheUsrMerge]</ref><ref>[https://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/ separate-usr-is-broken], примеры, где в ранней системе полагаются на наличие {{path|/usr}}}</ref>.<br />
<br />
'''Q: А что, если {{path|/usr}} на отдельном разделе по каким-то причинам не примонтируется?'''<br />
<br />
A: Тогда система не сможет загрузиться, как и в случае, если {{path|/}} по каким-то причинам не примонтируется.<br />
<br />
'''Q: А раньше можно было, пользуясь программами в {{path|/}}, починить {{path|/usr}}'''<br />
<br />
A: Несколько тезисов:<br />
* В-нулевых, для того, чтобы возникла такая ситуация, систему должны были установить так, чтобы {{path|/usr}} был отдельным от {{path|/}}, т. е. такая разметка преследовала какую-либо цель.<br />
* Во-первых, для этого нужно, чтобы {{path|/}} '''смог''' смонтироваться, а {{path|/usr}} '''не смог'''.<br />
* Во-вторых, всё ещё нет критерия, по которому ту или иную программу и её зависимости можно либо отнести к "системе спасения", либо исключить из неё и сослать в {{path|/usr}}.<br />
* В-третьих, нет ни одного задокументированного случая, где таким образом спасли какую-либо типичную GNU/Linux-систему, включая Альт, есть только [https://www.ecb.torontomu.ca/~elf/hack/recovery.html предание] из 1986 года, касавшееся non-Linux тех времён на компьютере тех времён. Рецептов такого восстановления, отчуждаемых от компетенций разработчиков ALT и умелых сисадминов, нет тем более. Следовательно, можно заключить, что в общем случае цитируемая возможность восстановить {{path|/usr}} из {{path|/}} — призрачна.<br />
* Несмотря на всё это, нет ничего плохого в том, чтобы рецепт такого спасения (при помощи операционной избыточности инсталляции альта) администратору ''предложить'', но это должен быть явный механизм с минимумом издержек для остальной структуры системы. Есть множество вариантов это реализовать с разными преимуществами и минусами в разных установках; все они out of scope for this document.<br />
<br />
== User-visible impact ==<br />
Меньше каталогов верхнего уровня в корне, кроме симлинков.<br />
<br />
== Appendix ==</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=Usrmerge&diff=78624Usrmerge2024-02-18T22:01:28Z<p>ArsenyMaslennikov: /* Стадия 1 */</p>
<hr />
<div>[[Категория:Sisyphus]]<br />
<br />
= Usrmerge =<br />
'''''Точный план действий сейчас вырабатывается, и его подробности могут измениться.'''''<br />
Статус воплощения отслеживается в {{altbug|46738}}.<br />
<br />
== Глоссарий ==<br />
'''{{term|merged-usr}}'''-иерархией называется такая FHS-подобная иерархия каталогов, в которой все неизменяемые при работе файлы из операционной системы (т. е. из состава пакетов в репозитории ОС) помещаются либо внутри префикса ({{path|/usr}}), либо их местоположение является ссылкой внутрь префикса. В такой иерархии {{path|/bin}}, {{path|/lib}} и т. д. будут симлинками на {{path|/usr/bin}}, {{path|/usr/lib}} и т. д. Иерархия, не отвечающая этому правилу (например, та, которую создавал инсталлятор до p11), называется '''{{term|unmerged-usr}}'''.<br />
<br />
'''{{term|split-usr}}'''-конфигурация подразумевает, что исполнимый файл в процессе pid 1 из корневой файловой системы стартует до монтирования {{path|/usr}}, расположенного на отдельном разделе. {{term|split-usr}} не следует путать с {{term|unmerged-usr}}, хоть системы со свойством {{term|split-usr}} и являются подмножеством систем {{term|unmerged-usr}}.<br />
<br />
== Введение ==<br />
Исторически<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|/}}, содержащего все эти подкаталоги.<br />
<br />
Позже, с увеличением средних размеров устройств хранения в машинах, сторонники разделения придумали другие обоснования (например, возможность из окружения в {{path|/{bin,sbin,libX,...}/}} починить немонтирующуюся {{path|/usr}}). Но на сегодняшний день непонятно, какой набор утилит и нужных им so/иных файлов стоит признать частью "системы спасения", которая должна быть доступна без {{path|/usr}}, а какой — нет, ибо сами утилиты приобретают универсальный вид и широкие границы применимости. С развитием механизмов initramfs и живых загрузочных/установочных носителей, а также практикой "раздела восстановления" на локальном хранилище машины среди настольных дистрибутивов этот аргумент теряет всякий смысл.<br />
<br />
Чем сохранять бесцельно дублирующие друг друга два класса мест для одних и тех же файлов, лучше оставить один из них, а другой устранить:<br />
* либо переложить {{path|/usr/{bin,sbin,lib,libx32,lib64,libexec,local,share,src,...}}} в корень,<br />
* либо поместить аналоги этих каталогов из {{path|/}} в {{path|/usr}}.<br />
<br />
Из двух вариантов, входящих в рамки FHS<ref>[https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf]</ref>, второй лучше хотя бы тем, что уменьшает количество top-level каталогов, куда упаковывается постоянное содержимое пакетов, до одного. Сейчас среди FHS-совместимых дистрибутивов это типичный подход, на который в том числе потихоньку начинают полагаться апстримы прикладных пакетов.<br />
<br />
== Rationale ==<br />
* Один каталог (пусть с не очень удачным именем {{path|/usr}}) как объект манипуляции и как общий носитель фиксированного содержимого пакетов удобнее россыпи каталогов, полный список которых даже невозможно построить. Появляется даже смысл рассматривать его в виде отдельной точки монтирования, которую можно держать общей на многих машинах под общим управлением.<br />
** Один каталог легче снапшотить, по нему легче гонять {{cmd|find}}, ...<br />
* Упаковка всего пакетного содержимого в {{path|/usr}} открывает дорогу к виртуальному {{path|/}}, который не находится на устройстве хранения и содержит только пустые каталоги-точки-монтирования.<br />
* Возникает осмысленное разделение между {{path|/usr}}, {{path|/var}} и {{path|/etc}}: первый каталог несёт в себе постоянное содержимое пакетов, не предназначенное к ручной модификации (не через пакетную систему или доставку образа), а другие два уже исторически применяются для переменного хранимого состояния и общесистемных конфигов.<br />
* Сборочным скриптам и прочим интеграционным программным компонентам не нужно будет перебирать каталоги, в которых находится искомая программа.<ref>Вообще-то для этого нужно ещё провести слияние sbin и bin, но оно не несёт срочности и не рассматривается на этой странице.</ref><br />
* Начиная с версии 255, выпущенной в декабре 2023, {{pkg|systemd}} [https://lists.freedesktop.org/archives/systemd-devel/2022-April/047673.html прекратит] поддержку split-usr и unmerged-usr; вот [https://github.com/systemd/systemd/pull/27999/commits/cedcd0bc61913db1e37e19f00d3f97fc72436728 коммит].<br />
** Из кода проекта {{pkg|systemd}}, помимо прочего, исчезнут все упоминания старых каталогов; например, директива <tt>ProtectKernelModules=</tt> больше не будет монтировать заглушку поверх <tt>/lib/modules</tt>, и т. п.<br />
<br />
== Proposed changes ==<br />
Необходимые действия можно разбить на две стадии.<br />
<br />
=== Стадия 1 ===<br />
* На стадии brp завершаться с ошибкой, если обнаружены разные файлы в {{path|/bin/x}} и {{path|/usr/bin/x}}, ...<br />
<br />
1) Определить, что слиянию с аналогами внутри /usr подлежат следующие каталоги:<br />
<pre><br />
/bin<br />
/lib<br />
/lib32<br />
/lib64<br />
/libx32<br />
/sbin<br />
</pre><br />
На каждой машине есть некоторые каталоги из этого списка; они и будут перенесены.<br />
<br />
2) Пакеты, кладущие эквивалентные файлы в {{path|/bin/x}} и {{path|/usr/bin/x}}, исправить так, чтобы они либо помещали файл ровно по одному из этих путей (не ломая работу пакета), либо устанавливали две копии такого файла по обоим путям с совпадающими атрибутами и контентом.<br />
Таким образом RPM сможет установить пакет и на unmerged-usr, и на merged-usr иерархию.<br />
Большинство пакетов, требующих исправления, достаточно будет просто пересобрать со специальным brp-модулем.<br />
<br />
3) Подготовить пакет {{pkg|filesystem}} версии 3: поместить в нём файлтриггер,<br />
который проверяет, не состоят ли каталоги из списка 1 целиком из<br />
симлинков внутрь {{path|/usr}}, и превращает такой каталог с симлинками в симлинк<br />
на каталог.<br />
Сценарий файлтриггера должен будет давать предельно ясную информацию и<br />
диагностические сообщения на стандартные потоки. Нужно будет либо<br />
положиться на static coreutils, либо очень осторожно обращаться с<br />
обычными и dynamic linker.<br />
<br />
4) Заменить макросы, использующие старые каталоги (<tt>%_udevrulesdir</tt>,<br />
<tt>%_tmpfilesdir</tt> и другие), и пересобрать с ними пакеты, что-либо<br />
помещающие в эти каталоги.<br />
Приближённое число затрагиваемых бинарных пакетов:<br />
<pre><br />
% grep -E '^/(bin|lib[^/]*|sbin)/[a-zA-Z0-9_-]+' contents-index \<br />
| grep -vE '^/lib/(systemd|udev|sysusers.d|modules[^/]*|modprobe.d|security|tmpfiles.d)'<br />
\ # exclude known places<br />
| cut -f2 -d$'\t' | grep -v '^/' # exclude path provides<br />
| sort -u | wc -l<br />
524<br />
</pre><br />
Это оценка по x86_64 + noarch. Исходных, конечно, будет меньше (333).<br />
<br />
При обновлении на эти пакеты будет действовать правило 2, поэтому их<br />
содержимое будет доступно.<br />
<br />
Некоторые пакеты, например, {{pkg|vim-common}}, сейчас упаковывают разные<br />
файловые объекты в {{path|/bin}} и {{path|/usr/bin}}; другие пакеты ставят файлы прямо<br />
в {{path|%buildroot/bin}}. Их потребуется исправить руками. (Справедливости ради,<br />
многие из них и так понадобится обновить)<br />
<br />
=== Стадия 2 ===<br />
Этот пункт вступает в действие на каждой машине индивидуально при<br />
обновлении её пакетов.<br />
Файлтриггер из пункта 3 обнаруживает, что можно ввести симлинки, и<br />
делает это, завершая процесс usrmerge на данной системе.<br />
<br />
Каждая инсталляция перейдёт к ней независимо, как только все пакеты в этой инсталляции будут содержать свои файлы под {{path|/usr}}.<br />
<br />
== Incompatibilities ==<br />
<br />
Если корневая файловая система — каскадная композиция на базе, например, overlayfs, и каталоги {{path|/bin}} и подобные находятся ''не в верхнем'' слое стека — автоматически обновить такую корневую файловую систему на {{pkg|filesystem > 3}} '''не выйдет'''. Придётся либо не обновляться, либо пересобрать контейнер/систему на обновлённой пакетной базе.<br />
<br />
== FAQ ==<br />
<br />
Рекомендуем прочитать другие материалы о преимуществах предлагаемого решения<ref>[https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ TheCaseForTheUsrMerge]</ref><ref>[https://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/ separate-usr-is-broken], примеры, где в ранней системе полагаются на наличие {{path|/usr}}}</ref>.<br />
<br />
'''Q: А что, если {{path|/usr}} на отдельном разделе по каким-то причинам не примонтируется?'''<br />
<br />
A: Тогда система не сможет загрузиться, как и в случае, если {{path|/}} по каким-то причинам не примонтируется.<br />
<br />
'''Q: А раньше можно было, пользуясь программами в {{path|/}}, починить {{path|/usr}}'''<br />
<br />
A: Несколько тезисов:<br />
* В-нулевых, для того, чтобы возникла такая ситуация, систему должны были установить так, чтобы {{path|/usr}} был отдельным от {{path|/}}, т. е. такая разметка преследовала какую-либо цель.<br />
* Во-первых, для этого нужно, чтобы {{path|/}} '''смог''' смонтироваться, а {{path|/usr}} '''не смог'''.<br />
* Во-вторых, всё ещё нет критерия, по которому ту или иную программу и её зависимости можно либо отнести к "системе спасения", либо исключить из неё и сослать в {{path|/usr}}.<br />
* В-третьих, нет ни одного задокументированного случая, где таким образом спасли какую-либо типичную GNU/Linux-систему, включая Альт, есть только [https://www.ecb.torontomu.ca/~elf/hack/recovery.html предание] из 1986 года, касавшееся non-Linux тех времён на компьютере тех времён. Рецептов такого восстановления, отчуждаемых от компетенций разработчиков ALT и умелых сисадминов, нет тем более. Следовательно, можно заключить, что в общем случае цитируемая возможность восстановить {{path|/usr}} из {{path|/}} — призрачна.<br />
* Несмотря на всё это, нет ничего плохого в том, чтобы рецепт такого спасения (при помощи операционной избыточности инсталляции альта) администратору ''предложить'', но это должен быть явный механизм с минимумом издержек для остальной структуры системы. Есть множество вариантов это реализовать с разными преимуществами и минусами в разных установках; все они out of scope for this document.<br />
<br />
== User-visible impact ==<br />
Меньше каталогов верхнего уровня в корне, кроме симлинков.<br />
<br />
== Appendix ==</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=Git.alt/%D0%A1%D0%BF%D1%80%D0%B0%D0%B2%D0%BE%D1%87%D0%BD%D0%B8%D0%BA&diff=78547Git.alt/Справочник2024-02-10T16:23:18Z<p>ArsenyMaslennikov: /* Сборка пакетов */ (TODO: дописать, почему это происходит)</p>
<hr />
<div>{{DISPLAYTITLE:git.alt/Справочник}}<br />
Эта страница документирует команды [[git.alt]], но не является [[Краткое руководство пользователя git.alt|кратким руководством]] или учебником по нему.<br />
<br />
__TOC__<br />
<br />
== Как воспользоваться <tt>git.alt</tt>? ==<br />
<br />
<tt>git.alt</tt> предоставляет несколько видов доступа:<br />
<br />
* ssh-доступ. Предоставляет несколько команд: для поиска репозиториев, их клонирования, создания, удаления, а также служебных.<br />
* <tt>ssh</tt>-, <tt>git</tt>-, <tt>rsync</tt>-, <tt>http</tt>-доступ для непосредственной работы с репозиториями.<br />
*: <tt>git</tt>-, <tt>rsync</tt>- и <tt>http</tt>-адреса предоставляют r/o доступ, <tt>ssh</tt> — r/w.<br />
* Web-интерфейс. Находится по адресу [http://git.altlinux.org/ git.altlinux.org], предоставляет навигацию по списку репозиториев и <tt>gitweb</tt> для индивидуальных репозиториев.<br />
<br />
Доступ по SSH выдаётся после [[Join|принятия]] в ALT Linux Team.<br />
<br />
<div id="access"></div><br />
<br />
<br />
=== Функции серверов сборки git.alt ===<br />
{{Важно|С 01.08.2015 г. для работы с git репозиторием надо настроить доступ к двум серверам :<br />
'''gitery.altlinux.org (gitery)''' и '''gyle.altlinux.org (girar)'''. См. [https://lists.altlinux.org/pipermail/devel/2015-August/199990.html <nowiki>[devel] I: git.alt ssh interface split</nowiki>] и [https://lists.altlinux.org/pipermail/devel/2019-February/206962.html <nowiki>[devel] I: legacy git.altlinux.org ssh interface is going to be retired soon</nowiki>].}}<br />
<br />
Функции между этими серверами разделены следующим образом:<br />
; gitery.altlinux.org:<br />
<br />
charset <path to git repository> [<charset>]<br />
clone <path to git repository> [<path to directory>]<br />
default-branch <path to git repository> [<branch>]<br />
find-package <pattern><br />
init-db <path to directory><br />
ls [<path to directory>]<br />
mv-db <path to source directory> <path to destination directory><br />
quota<br />
repack <path to git repository> [<value>]<br />
rm-db <path to git repository><br />
<br />
; gyle.altlinux.org<br />
<br />
help<br />
build [-b <binary_repository_name>] <gear_repo_1> <gear_tag_1> ...<br />
task {--help|ls|show|new|add|delsub|run|share|approve|rm} ...<br />
acl {--help|<binary_repository_name> ...}<br />
ls [<path to directory>]<br />
quota<br />
<br />
<br />
<tt>gitery.altlinux.org</tt> доступен по SSH по адресу <code>gitery.altlinux.org:222</code> и <code>gitery.altlinux.org:443</code>, gyle.altlinux.org — <code>gyle.altlinux.org:222</code> и <code>gyle.altlinux.org:443</code>. Аккаунт для доступа — <tt>alt_$USERNAME</tt>, где USERNAME — имя, присвоенное в процессе принятия в Team, с символами «-» заменёнными на «_». Обратите внимание: префикс <code>alt_</code> обязателен! Порт 443 можно использовать в случае, когда выход в интернет осуществляется только через прокси<ref>[[fsi:SSHFirewall|SSH через прокси]] — Freesource.info</ref>.<br />
<br />
=== SSH-доступ ===<br />
<br />
Для ssh доступа, надо отредактировать файл '''$HOME/.ssh/config'''<br />
<br />
Пример <tt>~/.ssh/config</tt><ref>Строки с # закомментированы, раскомментируйте, если вам нужен этот функционал</ref>:<br />
<source lang=text><br />
# Гитовница<br />
Host gitery<br />
HostName gitery.altlinux.org<br />
User alt_USERNAME # а не просто USERNAME!<br />
Port 222<br />
# Через прокси<br />
#ProxyCommand netcat -X connect -x proxy:3128 %h %p<br />
#Port 443<br />
# if stored separately<br />
#IdentityFile ~/.ssh/id_ed25519.alt<br />
# и если openssh-7.* или новее + ключ dsa, непременно<br />
#PubkeyAcceptedKeyTypes ssh-dss<br />
# иначе будет ошибка not in PubkeyAcceptedKeyTypes <br />
# Сборочница<br />
Host gyle<br />
HostName gyle.altlinux.org<br />
User alt_USERNAME # а не просто USERNAME!<br />
Port 222<br />
# Через прокси<br />
#ProxyCommand netcat -X connect -x proxy:3128 %h %p<br />
#Port 443<br />
</source><br />
Для работы с <tt>gitery</tt> необходимо настроить свой <tt>git</tt> — параметры <tt>user.name</tt>, <tt>user.email</tt>, <tt>user.signingkey</tt>:<br />
$ git config --global user.signingkey "<ID ключа GPG для подписи тэгов>"<br />
$ git config --global user.email "<ваш email, как мантейнера>"<br />
$ git config --global user.name "FirstName LastName"<br />
Например,<br />
$ git config --global user.signingkey 0xA26F54C8<br />
$ git config --global user.email dottedmag@altlinux.org<br />
$ git config --global user.name "Mikhail Gusarov"<br />
<br />
Чтобы узнать свой <tt>user.signingkey</tt>, выполните команду<br />
$ gpg --list-secret-keys<br />
Искомое значение находится в секции sec выхлопа команды. Его-то и следует прописать в переменную <tt>user.signingkey</tt>, предварительно снабдив символами <tt>0x</tt><br />
<br />
(Замечание: конфигурация может быть проще. Мне не потребовалось устанавливать значение <tt>user.signingkey</tt>; подписи в git и так работают, наверное, благодаря совпадению email с UID у gpg.)<br />
<br />
Список команд выдаётся при ssh-логине с командой <tt>help</tt>:<br />
<!---<br />
$ ssh gitery help<br />
Available commands:<br />
help<br />
charset <path to git repository> [<charset>]<br />
clone <path to git repository> [<path to directory>]<br />
default-branch <path to git repository> [<branch>]<br />
find-package <pattern><br />
init-db <path to directory><br />
ls [<path to directory>]<br />
mv-db <path to source directory> <path to destination directory><br />
quota<br />
repack <path to git repository> [<value>]<br />
rm-db <path to git repository><br />
task {--help|ls|show|new|add|delsub|run|share|approve|rm} ...<br />
build [-b <binary_repository_name>] <gear_repo_1> <gear_tag_1> ...<br />
acl {--help|<binary_repository_name> ...}<br />
--><br />
<br />
<source lang=bash><br />
$ ssh gitery help<br />
Available commands:<br />
help<br />
charset <path to git repository> [<charset>]<br />
clone <path to git repository> [<path to directory>]<br />
default-branch <path to git repository> [<branch>]<br />
find-package <pattern><br />
init-db <path to directory><br />
ls [<path to directory>]<br />
mv-db <path to source directory> <path to destination directory><br />
quota<br />
repack <path to git repository> [<value>]<br />
rm-db <path to git repository><br />
<br />
$ ssh gyle help<br />
Available commands:<br />
help<br />
build {--help | [options] <arguments> ...<br />
task {--help | <command> [options] ...<br />
acl {--help | <arguments> ...}<br />
quota<br />
</source><br />
<br />
Во всех командах суффикс директорий репозиториев <tt>.git</tt> опционален и может быть опущен. В выводе команд <tt>.git</tt> присутствует всегда.<br />
<br />
<!-- please don't remove -- there are links to #git etc --><br />
<div id="git"></div><br />
<br />
== Управление git-репозиториями ==<br />
<div id="ls"></div><br />
==== ls ====<br />
<br />
'''$ ssh gitery ls [<directory>]'''<br />
<br />
Эта команда позволяет посмотреть содержимое различных директорий на <tt>gitery</tt>:<br />
<br />
$ ssh gitery ls /people/dottedmag/public<br />
total 24<br />
drwxr-sr-x 5 4096 Jun 13 10:22 bugzilla-repo-sync.git<br />
...<br />
drwxr-sr-x 5 4096 Jul 7 18:03 wackoconvert.git<br />
$<br />
<br />
Без параметров — показывает содержимое <tt>/people/$USERNAME</tt>:<br />
<br />
$ ssh gitery ls<br />
total 16<br />
drwxr-s--- 5 4096 May 30 21:27 etc<br />
drwxr-sr-x 14 4096 Aug 13 23:53 packages<br />
drwxr-s--x 2 4096 Feb 13 2007 private<br />
drwxr-sr-x 8 4096 Aug 13 23:57 public<br />
$<br />
<br />
От этой же директории отсчитываются относительные пути:<br />
<br />
$ ssh gitery ls public<br />
total 24<br />
drwxr-sr-x 5 4096 Jun 13 10:22 bugzilla-repo-sync.git<br />
...<br />
drwxr-sr-x 5 4096 Jul 7 18:03 wackoconvert.git<br />
$<br />
<div id="find-package"></div><br />
==== find-package ====<br />
<br />
'''$ ssh gitery find-package <pattern>'''<br />
<br />
Эта команда позволяет искать репозитории по переданному шаблону. Единственный метасимвол, допустимый в шаблоне — <tt>*</tt>. Репозитории ищутся в директории <tt>packages</tt> каждого пользователя, поскольку предполагается, что <tt>[[gear]]</tt>-репозитории располагаются именно там.<br />
<br />
$ ssh gitery find-package 'glibc*'<br />
/people/avm/packages/glibc.git 1216320095<br />
...<br />
/people/peet/packages/glibc-kernheaders.git 1177084354<br />
/people/mike/packages/glibc-kvercheck.git 1160664813<br />
$ ssh gitery find-package glibc<br />
/people/avm/packages/glibc.git 1216320095<br />
...<br />
/people/peet/packages/glibc.git 1177084600<br />
$<br />
<br />
Вторая колонка в выводе <tt>find-package</tt> — unixtime времени последнего обновления репозитория. Получить время в привычном представлении можно с помощью команды <tt>date -d @unixtime</tt>.<br />
<br />
База данных для find-package обновляется в начале каждого часа.<br />
В неё попадают только те репозитории, в которые был сделан<br />
хотя бы один git push. Репозитории, не изменившиеся после<br />
первичного создания/клонирования, в эту базу не попадают.<br />
<div id="clone"></div><br />
==== clone ====<br />
<br />
'''$ ssh gitery clone <path to git repository> [<destination directory>]'''<br />
<br />
Эта команда позволяет «склонировать», то есть создать в своей директории копию репозитория для начала работы над ним. При этом локальные клоны (из /people) задействуют хардлинки, экономя дисковое пространство, а также ваши квоту на gitery и трафик до него.<br />
<br />
Без второго аргумента — клонирует в директорию <tt>packages</tt>:<br />
<br />
$ ssh gitery clone /people/ldv/packages/glibc<br />
gitery-clone: /people/dottedmag/packages/glibc.git<br />
$<br />
<br />
Вторым аргументом можно указать как директорию, в которую нужно поместить клон репозитория, так и название репозитория:<br />
<br />
$ ssh gitery clone /people/ldv/packages/glibc public/test<br />
gitery-clone: /people/dottedmag/public/test.git<br />
$<br />
<br />
Помимо /people, можно клонировать локальные репозитории, размещённые в /gears и /srpms:<br />
<br />
$ ssh gitery clone /gears/s/strace<br />
gitery-clone: /people/dottedmag/packages/strace.git<br />
$<br />
<br />
Можно также клонировать репозиторий, находящийся вне <tt>gitery</tt>:<br />
<br />
$ ssh gitery clone <nowiki>git://git.fedorahosted.org/chkconfig.git</nowiki><br />
gitery-clone: /people/dottedmag/packages/chkconfig.git<br />
$<br />
<div id="init-db"></div><br />
==== init-db ====<br />
<br />
'''$ ssh gitery init-db <path to directory>'''<br />
Позволяет создать новый git-репозиторий. По умолчанию (при указании только имени репозитория) репозиторий создаётся в директории <tt>packages</tt>:<br />
$ ssh gitery init-db test<br />
gitery-init-db: /people/dottedmag/packages/test.git<br />
При указании пути создаёт репозиторий по указанному пути:<br />
$ ssh gitery init-db public/test<br />
gitery-init-db: /people/dottedmag/public/test.git<br />
<div id="mv-db"></div><br />
==== mv-db ====<br />
<br />
'''$ ssh gitery mv-db <path to source directory> <path to destination directory>'''<br />
Позволяет перемещать и переименовывать свои репозитории. При указании только имени репозитория подразумевается директория <tt>packages</tt>.<br />
<br />
Перемещение packages/test.git в public/newname.git:<br />
$ ssh gitery mv-db test public/newname<br />
$<br />
Перемещение public/newname.git в packages/test.git:<br />
$ ssh gitery mv-db public/newname test<br />
$<br />
Переименовывание packages/test.git в packages/megatest.git:<br />
$ ssh gitery mv-db test megatest<br />
$<br />
<div id="rm-db"></div><br />
==== rm-db ====<br />
<br />
'''$ ssh gitery rm-db <path to git repository>'''<br />
Позволяет удалять свои репозитории. При указании только имени репозитория подразумевается директория <tt>packages</tt>:<br />
$ ssh gitery rm-db megatest # удаляет packages/megatest.git<br />
$ ssh gitery rm-db public/test<br />
<br />
<div id="acl"></div><br />
<br />
=== Управление ACL пакетов ===<br />
<br />
''Смотри [[ACL]] для общей информации об ACL пакетов в Sisyphus.''<br />
<br />
Команда <tt>acl</tt> требует указания репозитория, над которым производится работа. Список доступных репозиториев можно узнать у <tt>gyle</tt>:<br />
<br />
$ ssh gyle acl --help<br />
This is ACL (Approve Control List) management interface.<br />
<br />
Usage: girar-acl --list<br />
or: girar-acl <repository> [{<package>|@<group>} {check|show}]<br />
or: girar-acl <repository> [{<package>|@<group>} {add|del|leader|replace} {<login>|@<group>}...]<br />
or: girar-acl <repository><br />
<br />
Valid repositories are: c7 c8.1 p8 p9 sisyphus<br />
If no package is given, read commands from stdin, one command per line.<br />
See https://www.altlinux.org/Incoming/acl for details.<br />
$<br />
<br />
Если в командной строке указан только репозиторий, но не указана подкоманда, то список команд читается со стандартного ввода, по одной команде на строку, и выполняется тразакционно: ошибка в выполнении хотя бы одной команды отменяет действие всего набора команд:<br />
$ ssh gyle acl sisyphus keyjnote<br />
girar-acl: Go ahead and type your commands<br />
'''keyjnote add peet'''<br />
< keyjnote add peet<br />
> OK: keyjnote: dottedmag peet<br />
'''keyjnote add raorn'''<br />
< keyjnote add raorn<br />
> OK: keyjnote: dottedmag peet raorn<br />
'''^D'''<br />
girar-acl: 2 command(s) queued<br />
$<br />
<br />
Все команды, меняющие состав группы или ACL пакета, могут производиться только ''лидером'' — первым в списке ACL пакета или в составе группы. Набор из нескольких команд выполняется транзакционно. Результат выполнения acl-команд сообщается по email всем, кого они затрагивают.<br />
<br />
<div id="acl_show"></div><br />
==== acl show ====<br />
<br />
'''$ ssh gyle acl <binary repository> <package> show'''<br />
Показывает ACL указанного пакета<br />
<br />
$ ssh gyle acl sisyphus aMule show<br />
aMule oddity @qa @everybody<br />
<br />
'''$ ssh gyle acl <binary repository> @<group> show'''<br />
Показывает состав указанной группы майнтайнеров.<br />
<br />
$ ssh gyle acl sisyphus @python show<br />
@python ns ldv george akhavr bga lav swi at hiddenman sin mithraen kas<br />
<br />
==== acl check ====<br />
<br />
'''$ ssh gyle acl <binary repository> <package> check'''<br />
Проверяет ACL указанного пакета<br />
<br />
$ ssh gyle acl sisyphus bugzilla check<br />
girar-check-perms: access to bugzilla ALLOWED for ldv: project is orphaned<br />
<br />
==== acl add/del ====<br />
<br />
'''$ ssh gyle acl <binary repository> <package> add|del <login>|@<group> ...<br />
Добавляет/удаляет указанных пользователей и группы в/из ACL указанного пакета.<br />
<br />
'''$ ssh gyle acl sisyphus keyjnote add damir'''<br />
< keyjnote add damir<br />
> OK: keyjnote: dottedmag damir<br />
girar-acl: 1 command(s) queued<br />
'''$ ssh gyle acl sisyphus keyjnote del damir'''<br />
< keyjnote del damir<br />
> OK: keyjnote: dottedmag<br />
girar-acl: 1 command(s) queued<br />
<br />
'''$ ssh gyle acl <binary repository> @<group> add|del <login>|@<group> ...<br />
Добавляет/удаляет указанных пользователей и группы в/из указанной группы.<br />
<br />
'''$ ssh gyle acl sisyphus @python add ns'''<br />
< @python add ns<br />
> OK: @python: real ldv george lav swi at hiddenman sin mithraen enp vvk viy vitty ns<br />
girar-acl: 1 command(s) queued<br />
'''$ ssh gyle acl sisyphus @python del ns'''<br />
< @python del ns<br />
> OK: @python: real ldv george lav swi at hiddenman sin mithraen enp vvk viy vitty<br />
girar-acl: 1 command(s) queued<br />
<br />
==== acl replace ====<br />
<br />
'''$ ssh gyle acl <binary repository> <package>|@<group> replace <login>|@<group> <login>|@<group>'''<br />
Заменяет указанную запись в ACL пакета или составе группы на вторую указанную.<br />
<br />
$ ssh gyle acl sisyphus keyjnote replace dottedmag @python<br />
Заменяет в ACL пакета <tt>keyjnote</tt> запись <tt>dottedmag</tt> на <tt>@python</tt>.<br />
<br />
==== acl leader ====<br />
<br />
'''$ ssh gyle acl <binary repository> <package> leader <login>|@<group><br />
Устанавливает лидера пакета — указанного пользователя, или лидера указанной группы. Пользователь или группа, устанавливаемые лидерами, не обязаны присутствовать в списке ACL пакета до выполнения этой команды.<br />
<br />
$ ssh gyle acl sisyphus keyjnote leader @python<br />
<br />
'''$ ssh gyle acl <binary repository> @<group> leader <login>|@<group><br />
Устанавливает лидера группы — указанного пользователя, или лидера указанной группы. Пользователь или группа, устанавливаемые лидерами, не обязаны присутствовать в списке членов группы до выполнения этой команды.<br />
<br />
$ ssh gyle acl sisyphus @python leader ns<br />
<br />
<div id="build_tasks"></div><br />
<br />
== Сборка пакетов ==<br />
<br />
Для сборки пакетов используется механизм ''заданий'' — пользователь указывает, какие [[gear]]-репозитории необходимо собрать одной транзакцией, создавая задание, после чего запускает его на выполнение. Задание выполняются асинхронно. После завершения задания пользователю приходит отчёт по e-mail (плюс, отчёты о сборке доступны на git.alt, см. ниже). Каждое задание предназначено для изменения только одного репозитория пакетов.<br />
<div id="task"></div><br />
==== task ====<br />
<br />
'''$ ssh gyle task ls [--all]'''<br />
Показывает текущий список всех заданий пользователя с указанием их статуса и краткого содержания.<br /><br />
С указанием параметра <tt>--all</tt> показывает список заданий всех пользователей.<br />
'''$ ssh gyle task show [<task_id>]'''<br />
Показывает содержимое указанного (по умолчанию последнего созданного) задания.<br />
'''$ ssh gyle task new [<binary_repository_name>]'''<br />
Создаёт новое задание для сборки пакетов в указанный репозиторий пакетов (по умолчанию — Sisyphus).<br /><br />
Список репозиториев можно узнать с помощью <tt>task new --help</tt>.<br /><br />
По умолчанию задание создаётся в тестовом режиме (см. описание опции <tt>--commit</tt> ниже).<br /><br />
Данная команда выводит идентификатор задания на stdout.<br />
'''$ ssh gyle task add [<task_id> [<before_subtask_id>]] repo <gear_repo> <gear_tag>'''<br />
Добавляет в задание пакет, который необходимо собрать.<br /><br />
Пакет определяется двумя обязательными характеристиками: путём к gear-репозиторию и именем git-тега.<br /><br />
Вместе с указанным git-тегом из gear-репозитория выкачиваются все теги, помечающие достижимые из указанного тега коммиты.<br />
По умолчанию новые подзадания добавляются в конец списка подзаданий, с шагом 0100 (восьмеричное 100, или десятичное 64). Новое подзадание, добавляемое перед подзаданием номер N, получает восьмеричный номер (K+N)/2, где K — это номер подзадания, идущего непосредственно перед подзаданием номер N<ref>http://lists.altlinux.org/pipermail/devel-announce/2010-November/000035.html</ref>.<br />
'''$ ssh gyle task add [<task_id> [<before_subtask_id>]] srpm <srpm file>'''<br />
Добавляет в задание пакет, который необходимо собрать.<br /><br />
Пакет определяется именем предварительно отправленного на сервер путём ''rsync'' srpm-файла (Пример: <code>rsync grace-5.1.22-alt6.src.rpm girar:</code>).<br />
'''$ ssh gyle task add [<task_id> [<before_subtask_id>]] copy <package> [<binary_repository_name>]'''<br />
Добавляет в задание имя пакета, который необходимо скопировать из другого репозитория пакетов (по умолчанию — Sisyphus).<br />
<br />
Параметры:<br />
* '''package''' — имя пакета (без версии, релиза и расширения).<br />
'''$ ssh gyle task add [<task_id> [<before_subtask_id>]] del <package>'''<br />
Добавляет в задание имя пакета, который необходимо удалить из репозитория.<br />
'''$ ssh gyle task add [<task_id> [<before_subtask_id>]] rebuild <package>'''<br />
Добавляет в задание имя пакета, который необходимо пересобрать.<br />
Эта операция реализована только для тех пакетов, которые были собраны из git-репозиториев.<br />
'''$ ssh gyle task add [<task_id>] kmodules <kflavour>'''<br />
Добавляет в задание подзадания по пересборке всех актуальных модулей для указанного ядра.<br />
Эта операция имеет смысл только для модулей, которые были собраны из git-репозиториев с использованием gear specsubst.<br />
'''$ ssh gyle task delsub <task_id> <subtask_id>'''<br />
Удаляет из указанного задания подзадание с указанным номером.<br />
'''$ ssh gyle task deps [<task_id>] show'''<br />
Показывает список заданий, от которых зависит указанное (по умолчанию последнее созданное) задание.<br />
'''$ ssh gyle task deps [<task_id>] clear'''<br />
Очищает список заданий, от которых зависит указанное (по умолчанию последнее созданное) задание.<br />
'''$ ssh gyle task deps [<task_id>] add <required task id1> ...'''<br />
Добавляет перечисленные задания в список заданий, от которых зависит указанное (по умолчанию последнее созданное) задание.<br />
'''$ ssh gyle task deps [<task_id>] del <required task id1> ...'''<br />
Удаляет указанные задания из списка заданий, от которых зависит указанное (по умолчанию последнее созданное) задание.<br />
'''$ ssh gyle task deps [<task_id>] set <required task id1> ...'''<br />
Задает список заданий, от которых зависит указанное (по умолчанию последнее созданное) задание.<br />
<br />
'''<nowiki>$ ssh gyle task run [[--test-only|--commit]|[--hurry|--unhurry]] [--fail-early|--fail-late] [<task_id>]</nowiki>'''<br />
Отправляет на выполнение указанное (по умолчанию последнее созданное) задание.<br /><br />
Если ''не'' задан опциональный параметр <code>--commit</code> (либо явно заданы <code>--test-only</code> или <code>--hurry</code>), то финальное выкладывание собранного в репозиторий не производится (т.н. тестовая сборка; с опцией <code>--hurry</code> — ещё и без пересборки подзаданий в новой сборочной среде, что может ускорить получение отчёта о тесте, но и исказить его результаты).<br /><br />
Задание, отправленное на выполнение, начинает обрабатываться только после того, как успешно завершена обработка всех заданий, от которых оно зависит.<br /><br />
При сбое сборки на одной из архитектур поведение задания регулируется параметрами <code>--fail-early</code> (по умолчанию) либо <code>--fail-late</code>: в первом случае сборка задания будет при первой возможности прервана на ''всех'' архитектурах после первого же сбоя сборки подзадания на ''любой'' архитектуре; во втором архитектуры собираются независимо, но при наличии хотя бы одного сбоя сборки на ''любой'' из них задание в целом будет признано неудачным после завершения сборки на ''всех'' архитектурах. Кроме того, если установлен атрибут fail-early, то install check заканчивается после первой неудачи.<br /><br />
Задания, успешно собравшиеся в репозиторий (со статусом обработки <tt>DONE</tt>), архивируются сразу по окончании обработки<ref>NB: делитель для вычисления префикса в архиве по номеру задания составляет в данный момент 1024</ref>.<br /><br />
Остальные задания автоматически архивируются через установленное количество суток после завершения обработки (раньше: 14; сейчас: 28).<br />
'''$ ssh gyle task share [<task_id>] status|enabled|disabled'''<br />
Показывает или изменяет режим доступа к указанному (по умолчанию последнему созданному) заданию.<br /><br />
Задание с режимом доступа ''share enabled'' может быть дополнено другими пользователями с помощью команды <tt>task add</tt>.<br /><br />
По умолчанию задания создаются в режиме доступа ''share disabled''.<br />
<div id="task_approve"></div><br />
'''$ ssh gyle task approve <task_id> <subtask_id>'''<br />
Подтверждает сборку подзадания с указанным номером, входящего в состав указанного чужого задания.<br /><br />
Используется для разрешения сборки автором, не имеющим полномочий для обновления собираемого пакета (NMU).<br /><br />
Для отзыва выданного подтверждения применяется форма <code>task approve --revoke</code>.<br />
'''$ ssh gyle task check-git-inheritance <task_id> <subtask_number> disable <commit_sha_id>'''<br />
Для подзадания с номером <tt><subtask_number></tt>, входящего в состав задания <tt><task_id></tt>,<br />
выключается обязательность проверки наследования от git-коммита <commit_sha_id>.<br /><br />
Используется при необходимости осознанного обхода проверки наследования.<br />
<br />
'''$ ssh gyle task check-lastchange-inheritance <task_id> <subtask_number> disable <lastchange EVR>'''<br />
Для подзадания с номером <tt><subtask_number></tt>, входящего в состав задания <tt><task_id></tt>,<br />
выключается обязательность проверки наличия предыдущей записи changelog <lastchange EVR>.<br /><br />
Используется при необходимости осознанного обхода проверки наследования.<br />
<br />
'''$ ssh gyle task rm [<task_id>]'''<br />
Удаляет указанное (по умолчанию последнее созданное) задание.<br />
'''$ ssh gyle task abort <task_id>'''<br />
Досрочно прерывает обработку указанного задания.<br /><br />
Если задание еще не находится на обработке, то оно снимается с очереди на обработку сразу.<br /><br />
В противном случае оно помечается как задание, обработку которого следует прервать при первой возможности.<br />
<br />
Пример:<br />
$ ssh gyle task ls<br />
girar-task ls: no tasks for ldv<br />
$ ssh gyle task new<br />
1234<br />
new task #1234: owner=ldv repo=sisyphus<br />
$ ssh gyle task ls<br />
#1234 NEW sisyphus<br />
$ ssh gyle task show<br />
id=1234 locked=no shared=no repo=sisyphus owner=ldv seq= rc=<br />
$ ssh gyle task add repo vitmp 1.0-alt4<br />
task #1234: added #1 build tag 1.0-alt4 from /people/ldv/packages/vitmp.git<br />
$ ssh gyle task show<br />
id=1234 locked=no shared=no repo=sisyphus owner=ldv seq= rc=<br />
1:dir=/people/ldv/packages/vitmp.git<br />
1:tag_name=1.0-alt4<br />
1:tag_id=11c24aa6683506efd89b174de8dbea2af1cebf84<br />
1:tag_author=Dmitry V. Levin (for packages) <ldv@altlinux.org><br />
1:userid=ldv<br />
$ ssh gyle task run<br />
task #1234: queued, result will be emailed to ldv@altlinux.org<br />
$ ssh gyle task ls<br />
#1234 AWAITING sisyphus vitmp.git=1.0-alt4<br />
через некоторое время вывод последней команды изменится на<br />
#1234 BUILDING [locked] sisyphus vitmp.git=1.0-alt4<br />
а ещё через некоторое время — на<br />
#1234 DONE sisyphus vitmp.git=1.0-alt4<br />
(или TESTED, если сборка тестовая)<br />
<div id="build"></div><br />
<br />
==== build ====<br />
<br />
'''$ ssh gyle build [--test-only|--commit] [--fail-early|--fail-late] [-b <binary repository name>] [--deps <deps>] <build source 1> <build name 1> ...'''<br />
Эта команда создаёт задание по сборке указанных пакетов (их копированию и/или удалению, в зависимости от параметров) и отправляет его на выполнение, последовательно запуская <code>task new</code>, <code>task deps</code> (при указании ''--deps''), <code>task add</code> (для каждого ''build source'' и ''build name'') и <code>task run</code>.<br />
<br />
Параметр ''binary repository name'' имеет тот же смысл, что и в команде <code>task new</code>.<br />
<br />
Параметр ''deps'' имеет тот же смысл, что и в команде <code>task deps</code>.<br />
<br />
Параметры ''build source N'' и ''build name N'' имеют тот же смысл, что и в команде <code>task add</code>.<br />
<br />
Параметры <code>--test-only</code>, <code>--commit</code>, <code>--fail-early</code>, <code>--fail-late</code> имеют тот же смысл, что и в команде <code>task run</code>.<br />
<br />
Примеры:<br />
<br />
# сборка пакета в Сизиф<br />
$ ssh gyle build packages/test.git test-0.1-alt1<br />
# копирование пакета из Сизифа<br />
$ ssh gyle build -b t6 copy update-kernel<br />
# удаление пакета<br />
$ ssh gyle build -b t6 del linuxwacom<br />
<br />
<div id="reports"></div><br />
<br />
==== Отчёты о сборке ====<br />
<br />
Информация о сборках публикуется по адресу http://git.altlinux.org/tasks/<br />
<br />
Каждая поддиректория <tt>/tasks/</tt> содержит информацию об одной сборочной задаче. Идентификатор задачи выдаётся при её создании и указывается в почтовых оповещениях.<br />
<br />
Задача может состоять из нескольких подзадач. Информация о каждой подзадаче публиуется в директориях <tt>/tasks/<id>/build/<sid></tt> и <tt>/tasks/<id>/gears/<sid></tt>.<br />
<br />
Наиболее интересные файлы:<br />
; <id>/logs/<br />
: краткие логи сборки<br />
; <id>/build/<sid>/<arch>/srpm.log<br />
: лог подготовки сборки подзадачи для архитектуры <arch><br />
; <id>/build/<sid>/<arch>/log<br />
: лог сборки подзадачи для архитектуры <arch><br />
; <id>/gears/<sid><br />
: информация о подзадаче <sid>, если сборка производилась из gear-репозитория<br />
; <id>/gears/<sid>/git<br />
: частичный git-репозиторий, на основании которго собиралась подзадача <sid><br />
<br />
Более подробное описание структуры задания можно найти в [http://git.altlinux.org/people/ldv/packages/?p=girar-builder.git;a=blob_plain;f=TASK документации на girar-builder].<br />
<br />
Всё, что находится по адресу http://git.altlinux.org/tasks/, в равной<br />
степени доступно и по rsync.<br />
<br />
==== Лимиты сборочницы ====<br />
<br />
См. [[Hasher/Справочник#Лимиты на сборку у инкамингера]].<br />
<br />
== Вспомогательные команды ==<br />
<div id="charset"></div><br />
==== charset ====<br />
<br />
'''$ ssh gitery charset <path to git repository> [<charset>]'''<br />
<br />
Позволяет узнать или установить кодировку, используемую почтовым клиентом при отправке уведомлений, содержащих цитаты изменений файлов указанного git-репозитория:<br />
<br />
$ ssh gitery charset packages/glibc<br />
utf-8<br />
$ ssh gitery charset packages/glibc cp1252<br />
$ ssh gitery charset packages/glibc<br />
cp1252<br />
$<br />
<div id="quota"></div><br />
<br />
==== quota ====<br />
<br />
'''$ ssh gitery quota'''<br />
'''$ ssh gyle quota'''<br />
<br />
Позволяет узнать квоту и занимаемое пользователем дисковое пространство.<br />
<br />
$ ssh gitery quota<br />
Filesystem blocks quota limit grace files quota limit grace<br />
/dev/simfs 16932 977M 1465M 555 100k 150k <br />
$<br />
<br />
==== git-receive-pack, git-upload-pack ====<br />
<br />
Эти команды используются утилитами <tt>git push</tt>, <tt>git pull</tt> и подобными, и не предназначены для вызова пользователем.<br />
<br />
=== Клонирование и работа с репозиториями ===<br />
<br />
Работа с git-репозиториями, расположенными на <tt>gitery</tt>, ничем не отличается от работы с другими git-репозиториями.<br />
<br />
URL-ы репозиториев на gitery:<br />
; '''git''' (r/o)<br />
: <tt><nowiki>git://git.altlinux.org/people/$USER/(packages|public)/$PACKAGE.git</nowiki></tt><br />
; '''rsync''' (r/o)<br />
: <tt><nowiki>git.altlinux.org::people/$USER/(packages|public)/$PACKAGE.git</nowiki></tt><br />
; '''http/https''' (r/o)<br />
: <tt><nowiki>http://git.altlinux.org/people/$USER/(packages|public)/$PACKAGE.git</nowiki></tt><br />
или<br />
: <tt><nowiki>https://git.altlinux.org/people/$USER/(packages|public)/$PACKAGE.git</nowiki></tt><br />
; '''ssh''' (r/w)<br />
: <tt><nowiki>ssh://gitery:/people/$USER/(etc|packages|public|private)/$PACKAGE.git</nowiki></tt><br />
<br />
При этом хост <code>gitery</code> должен быть описан в <code>~/.ssh/config</code> так, как указано в статье [[Git.alt/Справочник#SSH-доступ]].<br />
<br />
URL-ы http:// и git:// репозиториев можно в любой момент узнать в [http://git.altlinux.org web-интерфейсе] <tt>git.alt</tt>.<br />
<br />
Внимание! Пустые (только что созданные через init-db) репозитории через http/https склонировать нельзя (но можно через ssh), см. [https://bugzilla.altlinux.org/42073 соответствующий багрепорт].<br />
<br />
=== Web-интерфейс ===<br />
<br />
Располагается по адресу http://git.altlinux.org/<br />
<br />
Предоставляет навигацию по<br />
* публичным репозиториям пользователей (по каталогам вида <tt>/people/$USERNAME/{packages,public}</tt>)<br />
* кэширующим репозиториям <tt>/gears</tt> и <tt>/srpms</tt><br />
* базе данных [[ACL]]<br />
* файлу <tt>people-packages-list</tt>, содержащий все репозитории из каталогов <tt>/people/$USERNAME/packages</tt> и даты их последнего изменения (в unixtime)<br />
* сборочным заданиям<br />
* логам тестовых пересборок Сизифа и бранчей<br />
* статистике непересобираемости пакетов в Сизифе и бранчах<br />
<br />
== Структура репозиториев ==<br />
<br />
<tt>gitery</tt> содержит три дерева репозиториев:<br />
<br />
* репозитории <tt>/people/$USERNAME</tt> для каждого зарегистрированного пользователя<br />
* репозитории <tt>/gears</tt> с исходным кодом для пакетов, собранных из gear-репозиториев.<br />
* репозитории <tt>/srpms</tt> с исходным кодом для пакетов, собранных из SRPM-пакетов.<br />
<br />
=== /people ===<br />
<br />
Каждому зарегистрированному на git.alt разработчику предоставляется место для git-репозиториев, начинающееся с <tt>/people/$USERNAME</tt>. Доступ на запись в эти директории даётся только владельцу. Структура для хранения репозиториев жёстко определена:<br />
<br />
==== /people/$USERNAME/etc ====<br />
<br />
Содержит репозитории <tt>packages.git</tt>, <tt>private.git</tt>, <tt>public.git</tt>, с помощью которых можно управлять [[#Почтовая подписка|подпиской на почтовые оповещения]]. Эти репозитории доступны на чтение только владельцу.<br />
<br />
==== /people/$USERNAME/packages ====<br />
<br />
Директория предназначена для хранения gear-репозиториев для пакетов Сизифа. Публично доступна.<br />
<br />
git-репозитории в этой директории будут искаться при выполнении команды <tt>find-package</tt>, и эта директория будет использоваться по умолчанию в командах <tt>init-db</tt>, <tt>clone</tt>, <tt>build</tt> и <tt>task add repo</tt><br />
<br />
==== /people/$USERNAME/private ====<br />
<br />
Директория предназначена для хранения приватных репозиториев, о существовании и содержании которых должно быть известно только самому разработчику.<br />
<br />
Для удобства работают прямые http-ссылки на файлы репозиториев, размещённых в этой директории.<br />
<br />
==== /people/$USERNAME/public ====<br />
<br />
Директория предназначена для хранения публичных git-репозиториев, не являющихся gear-репозиториями для пакетов Сизифа.<br />
<br />
<div id="gears"></div><br />
<br />
=== /gears ===<br />
<br />
В эту директорию помещаются gear-репозитории с исходным кодом пакетов Sisyphus и других [[Branches|стабильных веток]]. Добавление исходного кода в репозиторий <tt>/gears</tt> происходит после успешной сборки пакета с помощью команд <tt>gyle</tt> <tt>task</tt> или <tt>build</tt>.<br />
<br />
Каждый git-репозиторий в <tt>/gears</tt> назван по имени пакета с исходным кодом. Бранчи в нём называются по имени ветки, в которую собрался пакет (<tt>sisyphus</tt>, <tt>t6</tt> и т.д). Тэги в репозитории соответствуют собранным версиям пакетов (<tt>1.0-alt1</tt>, <tt>1.0-alt0.M50.1</tt> и т.д.).<br />
<br />
=== /srpms ===<br />
<br />
В этой директории размещаются git-репозитории с исходным кодом пакетов Sisyphus и других [[Branches|стабильных веток]], собранных из вручную подготовленных мейнтейнером SRPM-пакетов.<br />
<br />
<div id="email"></div><br />
<br />
== Почтовая подписка ==<br />
<br />
На <tt>gitery</tt> реализовано два вида почтовой подписки на события:<br />
* Пользователь подписывается на события, происходящие в репозиториях <tt>packages</tt> и <tt>public</tt>.<br />
* Пользователь подписывает кого-то на события, происходящие в '''его''' репозиториях <tt>packages</tt>, <tt>public</tt> и <tt>private</tt>.<br />
<br />
Для подписки используются репозитории из каталога <tt>etc</tt>: <tt>packages.git</tt>, <tt>public.git</tt>, <tt>private.git</tt> в каталоге пользователя. Схема работы с подписками напоминает работу с <tt>CVSROOT</tt> из CVS: пользователь клонирует нужный репозиторий, коммитит изменения в него и push-ит обратно на сервер, после чего изменения вступают в силу.<br />
<br />
В каждом из трёх репозиториев находится два файла: <tt>email-subscription</tt> и <tt>email-distribution</tt> (точнее, в <tt>private.git</tt> — только <tt>email-distribution</tt>).<br />
<tt>gitery</tt> использует бранч <tt>master</tt> и не обращает внимания на остальные бранчи в этих репозиториях.<br />
<br />
=== email-subscription ===<br />
<br />
Этот файл позволяет подписаться на события в публичных репозиториях <tt>gitery</tt>. Формат файла — последовательность строк следующего вида:<br />
$USER $PACKAGE $REFTYPE $REFNAME<br />
где<br />
* $USER — имя пользователя <tt>git.alt</tt>,<br />
* $PACKAGE — имя пакета,<br />
* $REFTYPE — вид изменения: <tt>head</tt> — новые/удалённые коммиты, <tt>tag</tt> — новые/удалённые тэги (техническая подробность: второй компонент из изменяемой ссылки <tt>refs/*/*</tt>)<br />
<!-- или release (релизы для сборки пакетов. Пока что не работает. --><br />
* $REFNAME — имя изменения: имя бранча для коммитов, имя тэга для тэгов (техническая подробность: третий и последующие компоненты из изменяемой ссылки <tt>refs/*/*</tt>).<br />
Каждое из полей может быть полным именем или вайлдкардом <tt>*</tt>. Для имён пакетов также разрешён вайлдкард в конце имени (например, <tt>docs-*</tt>).<br />
<br />
==== Примеры ====<br />
<br />
Подписка на все события во всех репозиториях:<br />
* * * *<br />
Подписка на новые/удалённые тэги в репозитории /people/ldv/packages/glibc.git:<br />
ldv glibc tag *<br />
Действия для осуществления подписки:<br />
git clone gitery:etc/packages.git<br />
cd packages<br />
echo 'ldv glibc tag *' >> email-subscription<br />
git commit -m "Subscribe to new tags in ldv's glibc repository" email-subscription<br />
git push<br />
<br />
=== email-distribution ===<br />
<br />
Этот файл позволяет подписать других пользователей <tt>gitery</tt> на события в ваших репозиториях. Формат файла — последовательность строк вида:<br />
$PACKAGE $REFTYPE $REFNAME $MAILTO<br />
где<br />
* $PACKAGE, $REFTYPE, $REFNAME аналогичны параметрам из файла email-subscription<br />
* $MAILTO — разделённый запятыми список имён пользователей <tt>gitery</tt> — получателей оповещения.<br />
Вайлдкарды в первых трёх полях допустимы так же, как и в email-subscription. Вайлдкарды в $MAILTO не допускаются.<br />
<br />
==Примечания==<br />
{{Примечания}}<br />
<references /><br />
<br />
== Ссылки ==<br />
<br />
=== Для начинающих мантейнеров: ===<br />
* [[Git| Всё о GIT, со слов ldv@]]<br />
* [http://www.tldp.org/HOWTO/RPM-HOWTO/ RPM-HOWTO]<br />
* [https://www.opennet.ru/docs/HOWTO-RU/RPM-HOWTO-48.html RPM-HOWTO перевод на русский]<br />
* [[Spec|Руководство по написанию спек файла для rpm]]<br />
<br />
{{Category navigation|title=git.alt|category=git.alt|sortkey={{SUBPAGENAME}}}}<br />
<br />
[[Категория:Справочники]]<br />
<br />
[[en:git.alt reference]]</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=Usrmerge&diff=78344Usrmerge2024-02-02T18:29:08Z<p>ArsenyMaslennikov: </p>
<hr />
<div>[[Категория:Sisyphus]]<br />
<br />
= Usrmerge =<br />
'''''Точный план действий сейчас вырабатывается, и его подробности могут измениться.'''''<br />
Статус воплощения отслеживается в {{altbug|46738}}.<br />
<br />
== Глоссарий ==<br />
'''{{term|merged-usr}}'''-иерархией называется такая FHS-подобная иерархия каталогов, в которой все неизменяемые при работе файлы из операционной системы (т. е. из состава пакетов в репозитории ОС) помещаются либо внутри префикса ({{path|/usr}}), либо их местоположение является ссылкой внутрь префикса. В такой иерархии {{path|/bin}}, {{path|/lib}} и т. д. будут симлинками на {{path|/usr/bin}}, {{path|/usr/lib}} и т. д. Иерархия, не отвечающая этому правилу (например, та, которую создавал инсталлятор до p11), называется '''{{term|unmerged-usr}}'''.<br />
<br />
'''{{term|split-usr}}'''-конфигурация подразумевает, что исполнимый файл в процессе pid 1 из корневой файловой системы стартует до монтирования {{path|/usr}}, расположенного на отдельном разделе. {{term|split-usr}} не следует путать с {{term|unmerged-usr}}, хоть системы со свойством {{term|split-usr}} и являются подмножеством систем {{term|unmerged-usr}}.<br />
<br />
== Введение ==<br />
Исторически<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|/}}, содержащего все эти подкаталоги.<br />
<br />
Позже, с увеличением средних размеров устройств хранения в машинах, сторонники разделения придумали другие обоснования (например, возможность из окружения в {{path|/{bin,sbin,libX,...}/}} починить немонтирующуюся {{path|/usr}}). Но на сегодняшний день непонятно, какой набор утилит и нужных им so/иных файлов стоит признать частью "системы спасения", которая должна быть доступна без {{path|/usr}}, а какой — нет, ибо сами утилиты приобретают универсальный вид и широкие границы применимости. С развитием механизмов initramfs и живых загрузочных/установочных носителей, а также практикой "раздела восстановления" на локальном хранилище машины среди настольных дистрибутивов этот аргумент теряет всякий смысл.<br />
<br />
Чем сохранять бесцельно дублирующие друг друга два класса мест для одних и тех же файлов, лучше оставить один из них, а другой устранить:<br />
* либо переложить {{path|/usr/{bin,sbin,lib,libx32,lib64,libexec,local,share,src,...}}} в корень,<br />
* либо поместить аналоги этих каталогов из {{path|/}} в {{path|/usr}}.<br />
<br />
Из двух вариантов, входящих в рамки FHS<ref>[https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf]</ref>, второй лучше хотя бы тем, что уменьшает количество top-level каталогов, куда упаковывается постоянное содержимое пакетов, до одного. Сейчас среди FHS-совместимых дистрибутивов это типичный подход, на который в том числе потихоньку начинают полагаться апстримы прикладных пакетов.<br />
<br />
== Rationale ==<br />
* Один каталог (пусть с не очень удачным именем {{path|/usr}}) как объект манипуляции и как общий носитель фиксированного содержимого пакетов удобнее россыпи каталогов, полный список которых даже невозможно построить. Появляется даже смысл рассматривать его в виде отдельной точки монтирования, которую можно держать общей на многих машинах под общим управлением.<br />
** Один каталог легче снапшотить, по нему легче гонять {{cmd|find}}, ...<br />
* Упаковка всего пакетного содержимого в {{path|/usr}} открывает дорогу к виртуальному {{path|/}}, который не находится на устройстве хранения и содержит только пустые каталоги-точки-монтирования.<br />
* Возникает осмысленное разделение между {{path|/usr}}, {{path|/var}} и {{path|/etc}}: первый каталог несёт в себе постоянное содержимое пакетов, не предназначенное к ручной модификации (не через пакетную систему или доставку образа), а другие два уже исторически применяются для переменного хранимого состояния и общесистемных конфигов.<br />
* Сборочным скриптам и прочим интеграционным программным компонентам не нужно будет перебирать каталоги, в которых находится искомая программа.<ref>Вообще-то для этого нужно ещё провести слияние sbin и bin, но оно не несёт срочности и не рассматривается на этой странице.</ref><br />
* Начиная с версии 255, выпущенной в декабре 2023, {{pkg|systemd}} [https://lists.freedesktop.org/archives/systemd-devel/2022-April/047673.html прекратит] поддержку split-usr и unmerged-usr; вот [https://github.com/systemd/systemd/pull/27999/commits/cedcd0bc61913db1e37e19f00d3f97fc72436728 коммит].<br />
** Из кода проекта {{pkg|systemd}}, помимо прочего, исчезнут все упоминания старых каталогов; например, директива <tt>ProtectKernelModules=</tt> больше не будет монтировать заглушку поверх <tt>/lib/modules</tt>, и т. п.<br />
<br />
== Proposed changes ==<br />
Необходимые действия можно разбить на две стадии.<br />
<br />
=== Стадия 1 ===<br />
* На стадии brp завершаться с ошибкой, если обнаружены разные файлы в {{path|/bin/x}} и {{path|/usr/bin/x}}, ...<br />
<br />
1. Определить, что слиянию с аналогами внутри /usr подлежат следующие каталоги:<br />
<pre><br />
/bin<br />
/lib<br />
/lib32<br />
/lib64<br />
/libx32<br />
/sbin<br />
</pre><br />
На каждой машине есть некоторые каталоги из этого списка; они и будут перенесены.<br />
<br />
2. Тем или иным образом научить rpm создавать симлинк вида<br />
<pre><br />
/bin/x -> ../usr/bin/x<br />
</pre><br />
..., если в пакете существует {{path|/usr/bin/x}} и <tt>Provides: /bin/x</tt>. Аналогично для всех каталогов из списка 1. Таким образом, на переходном этапе будет не нужно указывать в <tt>%files</tt> пакетов все эти симлинки, чтобы потом их убирать, и пакеты продолжат удовлетворять зависимостям на такие файлы.<br />
<br />
Важно, чтобы сначала удалялся старый путь, как обычно при установке<br />
пакета, а симлинк возникал после этой фазы.<br />
<br />
2.1) Бекпортировать поддержку в p10.<br />
<br />
3) Подготовить пакет {{pkg|filesystem}} версии 3: поместить в нём файлтриггер,<br />
который проверяет, не состоят ли каталоги из списка 1 целиком из<br />
симлинков внутрь {{path|/usr}}, и превращает такой каталог с симлинками в симлинк<br />
на каталог.<br />
Сценарий файлтриггера должен будет давать предельно ясную информацию и<br />
диагностические сообщения на стандартные потоки. Нужно будет либо<br />
положиться на static coreutils, либо очень осторожно обращаться с<br />
обычными и dynamic linker.<br />
<br />
4) Заменить макросы, использующие старые каталоги (<tt>%_udevrulesdir</tt>,<br />
<tt>%_tmpfilesdir</tt> и другие), и пересобрать с ними пакеты, что-либо<br />
помещающие в эти каталоги.<br />
Приближённое число затрагиваемых бинарных пакетов:<br />
<pre><br />
% grep -E '^/(bin|lib[^/]*|sbin)/[a-zA-Z0-9_-]+' contents-index \<br />
| grep -vE '^/lib/(systemd|udev|sysusers.d|modules[^/]*|modprobe.d|security|tmpfiles.d)'<br />
\ # exclude known places<br />
| cut -f2 -d$'\t' | grep -v '^/' # exclude path provides<br />
| sort -u | wc -l<br />
524<br />
</pre><br />
Это оценка по x86_64 + noarch. Исходных, конечно, будет меньше (333).<br />
<br />
При обновлении на эти пакеты будет действовать правило 2, поэтому их<br />
содержимое будет доступно.<br />
<br />
Некоторые пакеты, например, {{pkg|vim-common}}, сейчас упаковывают разные<br />
файловые объекты в {{path|/bin}} и {{path|/usr/bin}}; другие пакеты ставят файлы прямо<br />
в {{path|%buildroot/bin}}. Их потребуется исправить руками. (Справедливости ради,<br />
многие из них и так понадобится обновить)<br />
<br />
=== Стадия 2 ===<br />
Этот пункт вступает в действие на каждой машине индивидуально при<br />
обновлении её пакетов.<br />
Файлтриггер из пункта 3 обнаруживает, что можно ввести симлинки, и<br />
делает это, завершая процесс usrmerge на данной системе.<br />
<br />
Каждая инсталляция перейдёт к ней независимо, как только все пакеты в этой инсталляции будут содержать свои файлы под {{path|/usr}}.<br />
<br />
== Incompatibilities ==<br />
<br />
Если корневая файловая система — каскадная композиция на базе, например, overlayfs, и каталоги {{path|/bin}} и подобные находятся ''не в верхнем'' слое стека — автоматически обновить такую корневую файловую систему на {{pkg|filesystem > 3}} '''не выйдет'''. Придётся либо не обновляться, либо пересобрать контейнер/систему на обновлённой пакетной базе.<br />
<br />
== FAQ ==<br />
<br />
Рекомендуем прочитать другие материалы о преимуществах предлагаемого решения<ref>[https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ TheCaseForTheUsrMerge]</ref><ref>[https://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/ separate-usr-is-broken], примеры, где в ранней системе полагаются на наличие {{path|/usr}}}</ref>.<br />
<br />
'''Q: А что, если {{path|/usr}} на отдельном разделе по каким-то причинам не примонтируется?'''<br />
<br />
A: Тогда система не сможет загрузиться, как и в случае, если {{path|/}} по каким-то причинам не примонтируется.<br />
<br />
'''Q: А раньше можно было, пользуясь программами в {{path|/}}, починить {{path|/usr}}'''<br />
<br />
A: Несколько тезисов:<br />
* В-нулевых, для того, чтобы возникла такая ситуация, систему должны были установить так, чтобы {{path|/usr}} был отдельным от {{path|/}}, т. е. такая разметка преследовала какую-либо цель.<br />
* Во-первых, для этого нужно, чтобы {{path|/}} '''смог''' смонтироваться, а {{path|/usr}} '''не смог'''.<br />
* Во-вторых, всё ещё нет критерия, по которому ту или иную программу и её зависимости можно либо отнести к "системе спасения", либо исключить из неё и сослать в {{path|/usr}}.<br />
* В-третьих, нет ни одного задокументированного случая, где таким образом спасли какую-либо типичную GNU/Linux-систему, включая Альт, есть только [https://www.ecb.torontomu.ca/~elf/hack/recovery.html предание] из 1986 года, касавшееся non-Linux тех времён на компьютере тех времён. Рецептов такого восстановления, отчуждаемых от компетенций разработчиков ALT и умелых сисадминов, нет тем более. Следовательно, можно заключить, что в общем случае цитируемая возможность восстановить {{path|/usr}} из {{path|/}} — призрачна.<br />
* Несмотря на всё это, нет ничего плохого в том, чтобы рецепт такого спасения (при помощи операционной избыточности инсталляции альта) администратору ''предложить'', но это должен быть явный механизм с минимумом издержек для остальной структуры системы. Есть множество вариантов это реализовать с разными преимуществами и минусами в разных установках; все они out of scope for this document.<br />
<br />
== User-visible impact ==<br />
Меньше каталогов верхнего уровня в корне, кроме симлинков.<br />
<br />
== Appendix ==</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=%D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE_%D0%BF%D0%BE_gear&diff=78148Руководство по gear2024-01-27T18:23:03Z<p>ArsenyMaslennikov: gear-update-tag(1) is misleadingly named and deprecated; looks especially funny near gear-create-tag(1)</p>
<hr />
<div>[[Категория:Руководства|gear]]<br />
[[en:Gear/Introduction]]<br />
{{Stub}}<br />
<br />
== Паттерны ведения пакетов в <tt>gear</tt> ==<br />
<br />
<tt>gear</tt> спроектирован для сборки пакетов из произвольно устроенного <tt>git</tt>-репозитория, но при этом среди <tt>gear</tt>-репозиториев наиболее часто встречаются следующие варианты.<br />
<br />
TODO: gear-srpmimport, gear-buildreq, gear-changelog, gear-commit, gear[-remote][{,-hsh,-rpm}], [[Gear/gear-uupdate|gear-uupdate]].<br />
<br />
== «Родной» репозиторий ==<br />
<br />
Если пакет разрабатывается целиком в рамках Sisyphus, то в этом случае нет необходимости отслеживать upstream за неимением такового, так что репозиторий состоит из исходного кода, {{path|.spec}}-файла и тривиального {{path|.gear/rules}}.<br />
<br />
Типичный пример репозитория: [http://git.altlinux.org/people/ldv/packages/?p=girar.git;a=tree ldv/packages/girar].<br />
<br />
Типичный пример файла {{path|.gear/rules}}: [http://git.altlinux.org/people/ldv/packages/?p=girar.git;a=blob;f=.gear/rules;hb=HEAD ldv/packages/girar/.gear/rules].<br />
<br />
== Репозитории с импортированными upstream-тарболами ==<br />
<br />
TODO: gear-update<br />
<br />
=== «Линейный» репозиторий ===<br />
<br />
Репозитории такого вида наиболее близки к первоначальному виду <tt>src.rpm</tt>, в частности они создаются утилитой <tt>gear-srpmimport(1)</tt>. Такие репозитории содержат в одной ветке дерево (или несколько деревьев) немодифицированного исходного кода, набор патчей, дополнительных файлов, <tt>.spec</tt>-файл и файл <tt>.gear/rules</tt>.<br />
<br />
Типичный пример репозитория: [http://git.altlinux.org/people/ldv/packages/?p=net-tools.git;a=tree ldv/packages/net-tools].<br />
<br />
Типичный пример файла <tt>.gear/rules</tt>: [http://git.altlinux.org/people/ldv/packages/?p=net-tools.git;a=blob;f=.gear-rules;hb=HEAD ldv/packages/net-tools/.gear-rules].<br />
<br />
=== Репозиторий с отдельной веткой upstream ===<br />
<br />
В репозиториях такого вида обычно имеется две ветки: одна ветка хранит upstream-тарболы, импортируемые в неё с выходом каждой новой версии, во второй осуществляется пакетирование: в неё вливается ветка upstream-тарболов, в ней исправляются upstream-исходники при наличии необходимости, а также хранятся <tt>.spec</tt>-файл и <tt>.gear/rules</tt>.<br />
<br />
Типичный пример репозитория: [http://git.altlinux.org/people/ldv/packages/?p=bash.git;a=summary ldv/packages/bash].<br />
<br />
Типичный пример файла <tt>.gear/rules</tt>: [http://git.altlinux.org/people/ldv/packages/?p=bash.git;a=blob;f=.gear/rules;hb=HEAD ldv/packages/bash/.gear/rules].<br />
<br />
В отдельных случаях веток может быть больше двух:<br />
* если пакетирование производится под несколько веток разработки (Sisyphus, branches...), то каждой ветке выделяется своя <tt>git</tt>-ветка.<br />
* если в пакет входит несколько upstream-проектов, то для каждого upstream выделяется своя ветка с тарболами.<br />
<br />
Пример пакета для нескольких веток разработки: [http://git.altlinux.org/people/ldv/packages/?p=pcre.git;a=summary ldv/packages/pcre].<br />
<br />
TODO: gear-merge, gear-create-tag, gear-store-tags.<br />
<br />
=== Репозиторий с отдельной веткой upstream и topic-ветками ===<br />
<br />
В случае, когда upstream-код требует интенсивной обработки, иногда применяется схема, являющаяся развитием предыдущей. В этой схеме используется целый набор веток:<br />
* ветка для импортирования хранения upstream-тарболов,<br />
* набор веток, в каждой из которых развивается какое-то целостное изменение (topic). Каждая из таких веток ответвляется от upstream-ветки,<br />
* ветка для пакетирования. В эту ветку сливаются topic-ветки, а также в ней хранятся {{path|.spec}}-файл и файл {{path|.gear/rules}}.<br />
<br />
Типичный пример репозитория: [http://git.altlinux.org/people/ldv/packages/?p=kernel-image-2.6.18.git;a=summary ldv/packages/kernel-image-2.6.18] — ветки {{pkg|fix-*}} содержат отдельные исправления, а {{pkg|kernel-image-ovz-smp}} и {{pkg|kernel-image-std-smp}} — пакетирование.<br />
<br />
Аналогично предыдущей схеме, в этом случае могут присутствовать множественные upstream-ветки и ветки для пакетирования.<br />
<br />
См. также [[Git/MergingBranches]].<br />
<br />
=== Репозиторий с отдельными ветками для upstream и патчей ===<br />
<br />
Этот вариант очень близок к [[Руководство по gear#Репозиторий с отдельной веткой upstream и topic-ветками|Репозиторий с отдельной веткой upstream и topic-ветками]].<br />
<br />
Как для не модифицированных исходников ({{pkg|upstream}} или {{pkg|origin/master}}), так и для каждого патча ({{pkg|patches/*}}), создаётся отдельная ветка. ''(Таким образом можно легко отделить каждое изменение).'' Для пакетирования используется отдельная ветка (например, {{pkg|master}}). ''(Она не содержит код программы).''<br />
<br />
Для успешной сборки нужно делать {{cmd|git merge -s ours}} использованных веток в ветку для пакетирования, и записать в {{path|.gear/rules}} например следующее:<br />
<pre><br />
tar: upstream:. name=@name@<br />
diff: upstream:. patches/alt/build:. name=@name@-alt-build.patch<br />
</pre><br />
<br />
Пример репозитория: [http://git.altlinux.org/people/ildar/packages/?p=gnome-subtitles.git;a=tag;h=refs/tags/0.8.git_149_g56dc021-alt1 ildar/packages/gnome-subtitles]<br />
<br />
<br />
См. также [[Git/MergingBranches#если предпочитаете держать патчи не приложенными]].<br />
<br />
== Репозитории с импортированной историей upstream ==<br />
<br />
Для большего удобства работы с upstream-исходниками и для упрощения коммуникации с upstream-разработчиками в этом виде репозиториев вместо тарболов в <tt>git</tt>-репозиторий целиком импортируется история upstream-репозитория: вместо отдельных огромных коммитов в upstream-ветку в репозитории находится полное upstream-дерево с тэгами, ветками и т.д.<br />
<br />
Пример репозитория с импортированной историей upstream (импорт из CVS): [http://git.altlinux.org/people/ldv/packages/?p=genromfs.git;a=summary ldv/packages/genromfs].<br />
<br />
Пример репозитория с импортированной историей upstream (импорт из git), а также отдельными ветками для пакетирования в разные ветки разработки: [http://git.altlinux.org/people/ldv/packages/?p=git.git;a=summary ldv/packages/git].<br />
<br />
Пример репозитория с несколькими отдельными upstream-ветками с импортированной историей upstream: [http://git.altlinux.org/people/ldv/packages/?p=gnulib.git;a=summary ldv/packages/gnulib].<br />
<br />
Конечно, в репозитории с импортированной историей upstream ничто не мешает поступать как в [[Руководство по gear#Репозиторий с отдельной веткой upstream и topic-ветками|Репозиторий с отдельной веткой upstream и topic-ветками]] или в [[Руководство по gear#Репозиторий с отдельными ветками для upstream и патчей|Репозиторий с отдельными ветками для upstream и патчей]]. (Чтобы помочь вести репозитории со своими патчами (возможно, зависимыми между собой) по таким схемам и коммуницировать с upstream существет довольно широко известная утилита topgit. Она неспецифична для maintainer-ства пакетов в дистрибутиве, а общего назначения. См. [[Git/MergingBranches#topgit]].)<br />
<br />
TODO: засасывание исходников, конверсия репозиториев.<br />
{{Category navigation|title=gear|category=gear|sortkey={{SUBPAGENAME}}}}</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=Gear/tags&diff=78147Gear/tags2024-01-27T18:20:00Z<p>ArsenyMaslennikov: gear-update-tag(1) is misleadingly named and deprecated</p>
<hr />
<div>{{stub}}<br />
== Пример использования .gear/tags ==<br />
<br />
Цель использования gear tags — получить в .src.rpm-е тарбол оригинальных сырцов + кумулятивный патч наших изменений.<br />
<br />
Структура репозитория должна быть примерно такой:<br />
* '''upstream''' — сюда импортятся оригинальные тарболы один за другим, при этом проставляются таги с именем «vверсия», то есть v1.0, v2.0, v3.0 и т.д<br />
* '''master''' — это наш рабочий бранч, тут мы храним спек, дополнительные sources и изменённые исходники. На каждый релиз пакета проставляются таги вида %version-%release, то есть 1.0-alt1, 1.0-alt2, 1.0-alt3 и т. д.<br />
'''master''' и '''upstream''' связаны следующим образом: когда-то, сразу после прикладывания патчей (версия нашего проекта foo совпадает в master и upstream) для создания общего base, в бранче master был выполнен<br />
<pre>git merge -s ours upstream</pre><br />
<br />
В дальнейшем, при обновлении версии, производится<br />
<pre>git merge upstream</pre><br />
<br />
При этом все наши интегрированные патчи, спек, sources — сохраняются. Если возникает конфликт, git об этом напишет, остаётся лишь устранить его (например, воспользовавшись '''git mergetool''').<br />
<br />
Для реализации поставленной задачи необходимо несколько вникнуть в применение директив файла '''.gear/rules''', и соответствующим образом его модифицировать. Найти информацию можно в заголовке '''/usr/bin/gear''' или в man-странице '''gear-rules(5)'''<br />
<br />
Итак, нам необходимо, чтобы в тарбол помещалось оригинальное дерево исходников:<br />
<pre>tar: v@version@:foo</pre><br />
<br />
В данном случае мы говорим, что в tar-файл необходимо завернуть директорию '''foo''', которая должна быть взята из тага '''v@version@'''. Так же можно использовать не таг, а непосредственно идентификатор коммита (sha1 хэш).<br />
'''@version@''' — это тот тег '''Version:''', что прописан в спеке.<br />
<br />
Теперь нужно сделать кумулятивный diff:<br />
<pre>diff: v@version@:foo foo</pre><br />
Здесь тоже всё просто — делается diff между директорией foo тага '''v@version@''' и директорий '''foo''' из текущего бранча ('''master'''). Имя diff-а по умолчанию '''%name-%version-%release.patch'''. Разумеется, название diff-а в спеке должно указывать на правильный patch-файл.<br />
<br />
Осталось сформировать файл с состоянием тэгов на текущий момент времени (этот файл в дальнейшем позволит пересобирать пакет вне зависимости от того, куда и как были переставлены тэги, упоминаемые в файле <tt>.gear/rules</tt>). Для этого предназначена специальная утилита '''gear-store-tags(1)'''<br />
<pre>gear-store-tags -ac</pre><br />
<br />
И не забыть закоммитить:<br />
<pre>git commit -a -m 'Switched to use .gear/tags'</pre><br />
<br />
==Накладываемые ограничения==<br />
Ограничения, накладываемые на ссылки на другие коммиты, необходимы для того, чтобы репозиторий, содержащий основной коммит, содержал всё, что требуется для однозначного извлечения исходного кода.<br />
<br />
В частности, если в коммите C вы ссылаетесь на некоторый коммит с помощью .gear/rules, то необходимо, чтобы этот коммит был среди предков коммита C -- тогда git обеспечит обязательное присутствие коммита в репозитории до тех пор, пока в нём находится коммит C.<br />
<br />
Идея, лежащая в основе ограничения, простая: необходимо обеспечить, чтобы всякий раз из коммита C собиралось одно и то же.<br />
<br />
<br />
{{Category navigation|title=gear|category=gear|sortkey={{SUBPAGENAME}}}}</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=ACLAdmin&diff=78138ACLAdmin2024-01-27T17:02:31Z<p>ArsenyMaslennikov: </p>
<hr />
<div>{{Stub}}<br />
<br />
'''Администратор ACL''' — член [[Team]], имеющий права на управление ACL репозитория.<br />
<br />
Администратор ACL имеет право:<br />
* выдавать одобрение NMU на пакеты согласно Policy,<br />
* менять ACL на пакеты согласно Policy,<br />
<br />
Новый или дополнительный администратор ACL назначается текущим [[RepositoryAdmin|администратором репозитория]], по согласованию с другими участниками Team.<br />
<br />
В случае отсуствия Администратора ACL в репозитории, всё управление ACL берёт на себя [[RepositoryAdmin|Администратор репозитория]] <br />
<br />
{{Category navigation|title=Team|category=Team|sortkey=*}}</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=ACLAdmin&diff=78137ACLAdmin2024-01-27T17:02:13Z<p>ArsenyMaslennikov: ну сколько можно-то</p>
<hr />
<div>{{Stub}}<br />
<br />
'''Администратор ACL''' — член [[Team]], имеющий права на управление ACL репозитория.<br />
<br />
Администратор ACL имеет право:<br />
* выдавать NMU на пакеты согласно Policy,<br />
* менять ACL на пакеты согласно Policy,<br />
<br />
Новый или дополнительный администратор ACL назначается текущим [[RepositoryAdmin|администратором репозитория]], по согласованию с другими участниками Team.<br />
<br />
В случае отсуствия Администратора ACL в репозитории, всё управление ACL берёт на себя [[RepositoryAdmin|Администратор репозитория]] <br />
<br />
{{Category navigation|title=Team|category=Team|sortkey=*}}</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=Branches/p11/TechnicalNotes&diff=77760Branches/p11/TechnicalNotes2024-01-23T12:28:38Z<p>ArsenyMaslennikov: </p>
<hr />
<div>{{Stub}}<br />
<br />
[[Категория:Branches]]<br />
<br />
<!-- Не знаю пока, как должно выглядеть оглавление этой страницы, и аналогов в прошлые разы мы не делали. Совсем по-другому строить куст страниц про p11 я тоже не решился. --~~~~ --><br />
<br />
== Что нового в p11 ==<br />
<br />
=== Интерфейс пользователя ===<br />
* Диалоговый шелл по умолчанию {{cmd|/bin/bash}} обновлён до Bash 5.2.<br />
<br />
=== Системные компоненты ===<br />
* Системный интерпретатор сценариев {{cmd|/bin/sh}} теперь также основан на Bash 5.2 вместо Bash 4. Рекомендуем ознакомиться со [https://git.savannah.gnu.org/cgit/bash.git/tree/CHANGES?id=74091dd4e8086db518b30df7f222691524469998 списком изменений] от апстрима GNU Bash, в числе которых могут быть обратно несовместимые изменения.<br />
<br />
=== Весь репозиторий ===<br />
* Каталоги {{path|/bin}}, {{path|/sbin}}, {{path|/lib*}} [[Usrmerge|объединены]] с аналогами в {{path|/usr}}. Миграция происходит при обновлении пакета {{pkg|filesystem}} на версию из состава p11. При свежей установке p11 {{path|/bin}}, {{path|/sbin}}, {{path|/lib*}} сразу являются симлинками на аналоги в {{path|usr/}}.<br />
** <!-- Это фрагмент для любознательных, "материал со звёздочкой". Вместо small: стоит ли спрятать его под раскрываемый спойлер или серенький admonition? Как это принято делать на mediawiki? --> <small>В неопределённом будущем планируется научить инсталлятор формировать recovery-раздел при установке на носитель достаточного объёма. Его создание можно будет отключить по желанию администратора. С его помощью пользователь персоналки или администратор сможет восстановить основную систему.</small><br />
* Для пользователя <tt>nobody</tt> изменён uid с 99 на значение (65536-2), равное значению [https://docs.kernel.org/admin-guide/sysctl/fs.html#overflowgid-overflowuid overflowuid] в наших ядрах.<br />
* В репозитории разрешены пакеты с символом <tt>~</tt> в версии или релизе. Тильда признана лексикографически старше конца строки, по аналогии с <tt>sort -V</tt> и предназначена для обозначения версий типа release candidate, например, <tt>1.2~rc2</tt>. Это не повлияет на обновление с p9 и p10.<br />
* В репозитории обеспечена поддержка параллельной установки нескольких мажорных ветвей проекта [[LLVM]] одновременно. Утилиты, подобно проекту gcc, устанавливаются с суффиксом, содержащим номер версии (например, <tt>clang-17</tt>). Доступна обёртка с именем без суффикса, которая вызывает команду нужной версии. [[LLVM/Packaging|Подробнее]]<br />
<br />
{{Category navigation|title=Одиннадцатая платформа|category=Одиннадцатая платформа}}</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=NobodySubjectPolicy&diff=77383NobodySubjectPolicy2024-01-08T10:23:39Z<p>ArsenyMaslennikov: </p>
<hr />
<div>{{Policy<br />
|responsible=arseny@<br />
|since=2023-12-20<br />
}}<br />
<br />
== Введение ==<br />
Как известно, в файле {{term|passwd}} по умолчанию в наших системах присутствуют пользователь и группа {{term|nobody}}.<br />
<br />
Одно время в кругу разработчиков и администраторов ходила мода считать этого пользователя "наименее привилегированным", будто ему почти ничего нельзя: в ФС почти нет файлов, ему доступных, у него нет логин-шелла, под ним нельзя запустить десктоп штатными средствами, и т. д.<br />
Из этого выводили ошибочное следствие, что какой-нибудь нетребовательный процесс-службу можно запускать прямо под {{term|nobody}}, чтобы отсечь ему доступ к "более важным" службам.<br />
Как только таких сервисов становится больше одного, оказывается, что все они работают с общими привилегиями, могут слать друг другу сигналы и т. д., то есть недостаточно изолированы друг от друга.<br />
Им просто следует работать под собственными системными UID, а концепция "наименее привилегированного uid" не имеет смысла.<br />
<br />
В [[Kernel|ядре Linux]] достаточно давно есть [https://docs.kernel.org/admin-guide/sysctl/fs.html#overflowgid-overflowuid понятие] {{term|overflowuid}}/{{term|overflowgid}}:<br />
зарезервированное значение uid и gid, которое используется, чтобы обозначить в одной подсистеме непредставимые значения uid и gid в файлах из другой подсистемы.<br />
Например, в файловых системах с 16-разрядными полями uid и gid вместо невлезающего значения будет записан {{term|overflowuid}}/{{term|overflowgid}}.<br />
Другой пример: NFS-клиент может представлять рута на клиентской машине {{term|overflowuid}}ом на сервере.<br />
Ныне разнородные апстримы сходятся на том, чтобы зафиксировать в качестве этого значения число <tt>((uint16_t)-2)</tt>, оно же <tt>65534</tt>, дефолт в ядре, и обозвать этого пользователя {{term|nobody}}. Тем самым они ''объединяют'' понятия {{term|nobody}} и {{term|overflow[ug]id}}.<br />
<br />
Вообще говоря, под пользователем {{term|nobody}} и группой {{term|nobody}} в системе не должно работать ничего, а в ФС на несъёмных устройствах хранения не должно создаваться файловых объектов с такими uid и gid.<br />
Для того, чтобы это гарантировать, следует ввести автоматические проверки хотя бы на этапе сборки пакетов.<ref>А лучше даже во время работы системы (что-то вроде seccomp-фильтра на всех процессах, запрещающего setuid и setgid в этого пользователя), но это более сложная задача, решения которой на ванильном ядре могут оказаться сверхнеэффективными.</ref><br />
<br />
== Нормативные предписания ==<br />
<small>Здесь и далее словосочетание "под {{term|nobody}}" сохраняет свой общепринятый смысл, но относится и к uid, и к основному gid.</small><br />
* В пакеты '''запрещается''' помещать файловые объекты под {{term|nobody}}. Исполнение правила контролирует sisyphus-check;<br />
* Мейнтейнеры не должны допускать, чтобы собираемые ими системные службы исполняли код под {{term|nobody}} или имели {{term|nobody}} в числе дополнительных (''supplementary'') групп. Исполнение правила призван гарантировать brp-скрипт при сборке пакета;<br />
* Администраторам систем на базе Альт рекомендуется не запускать процессы под пользователем и группой {{term|nobody}} или помещать {{term|nobody}} в число дополнительных (''supplementary'') групп.<br />
<br />
== FAQ ==<br />
'''Q:''' Что будет, если записать на флешку файлы с uid/gid 65534 и подключить её к системе?<br />
<br />
'''A:''' Система воспримет такие файлы как файлы с непонятным uid/gid. Эти uid/gid нет смысла, например, сравнивать с другими и (что важно) друг с другом. Процесс с {{term|CAP_DAC_OVERRIDE}} и т. п., как обычно, сможет сделать с ними всё, что угодно.<br />
<br />
== Примечания ==</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=NobodySubjectPolicy&diff=77375NobodySubjectPolicy2024-01-08T09:27:59Z<p>ArsenyMaslennikov: </p>
<hr />
<div>{{Policy<br />
|responsible=arseny@<br />
|since=2023-11-15<br />
}}<br />
<br />
== Введение ==<br />
Как известно, в файле {{term|passwd}} по умолчанию в наших системах присутствуют пользователь и группа {{term|nobody}}.<br />
<br />
Одно время в кругу разработчиков и администраторов ходила мода считать этого пользователя "наименее привилегированным", будто ему почти ничего нельзя: в ФС почти нет файлов, ему доступных, у него нет логин-шелла, под ним нельзя запустить десктоп штатными средствами, и т. д.<br />
Из этого выводили ошибочное следствие, что какой-нибудь нетребовательный процесс-службу можно запускать прямо под {{term|nobody}}, чтобы отсечь ему доступ к "более важным" службам.<br />
Как только таких сервисов становится больше одного, оказывается, что все они работают с общими привилегиями, могут слать друг другу сигналы и т. д., то есть недостаточно изолированы друг от друга.<br />
Им просто следует работать под собственными системными UID, а концепция "наименее привилегированного uid" не имеет смысла.<br />
<br />
В [[Kernel|ядре Linux]] достаточно давно есть [https://docs.kernel.org/admin-guide/sysctl/fs.html#overflowgid-overflowuid понятие] {{term|overflowuid}}/{{term|overflowgid}}:<br />
зарезервированное значение uid и gid, которое используется, чтобы обозначить в одной подсистеме непредставимые значения uid и gid в файлах из другой подсистемы.<br />
Например, в файловых системах с 16-разрядными полями uid и gid вместо невлезающего значения будет записан {{term|overflowuid}}/{{term|overflowgid}}.<br />
Другой пример: NFS-клиент может представлять рута на клиентской машине {{term|overflowuid}}ом на сервере.<br />
Ныне разнородные апстримы сходятся на том, чтобы зафиксировать в качестве этого значения число <tt>((uint16_t)-2)</tt>, оно же <tt>65534</tt>, дефолт в ядре, и обозвать этого пользователя {{term|nobody}}. Тем самым они ''объединяют'' понятия {{term|nobody}} и {{term|overflow[ug]id}}.<br />
<br />
Вообще говоря, под пользователем {{term|nobody}} и группой {{term|nobody}} в системе не должно работать ничего, а в ФС на несъёмных устройствах хранения не должно создаваться файловых объектов с такими uid и gid.<br />
Для того, чтобы это гарантировать, следует ввести автоматические проверки хотя бы на этапе сборки пакетов.<ref>А лучше даже во время работы системы (что-то вроде seccomp-фильтра на всех процессах, запрещающего setuid и setgid в этого пользователя), но это более сложная задача, решения которой на ванильном ядре могут оказаться сверхнеэффективными.</ref><br />
<br />
== Нормативные предписания ==<br />
<small>Здесь и далее словосочетание "под {{term|nobody}}" сохраняет свой общепринятый смысл, но относится и к uid, и к основному gid.</small><br />
* В пакеты '''запрещается''' помещать файловые объекты под {{term|nobody}}. Исполнение правила контролирует sisyphus-check;<br />
* Мейнтейнеры не должны допускать, чтобы собираемые ими системные службы исполняли код под {{term|nobody}} или имели {{term|nobody}} в числе дополнительных (''supplementary'') групп. Исполнение правила призван гарантировать brp-скрипт при сборке пакета;<br />
* Администраторам систем на базе Альт рекомендуется не запускать процессы под пользователем и группой {{term|nobody}} или помещать {{term|nobody}} в число дополнительных (''supplementary'') групп.<br />
<br />
== FAQ ==<br />
'''Q:''' Что будет, если записать на флешку файлы с uid/gid 65534 и подключить её к системе?<br />
<br />
'''A:''' Система воспримет такие файлы как файлы с непонятным uid/gid. Эти uid/gid нет смысла, например, сравнивать с другими и (что важно) друг с другом. Процесс с {{term|CAP_DAC_OVERRIDE}} и т. п., как обычно, сможет сделать с ними всё, что угодно.<br />
<br />
== Примечания ==</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=%D0%9E%D0%B4%D0%B8%D0%BD%D0%BD%D0%B0%D0%B4%D1%86%D0%B0%D1%82%D0%B0%D1%8F_%D0%BF%D0%BB%D0%B0%D1%82%D1%84%D0%BE%D1%80%D0%BC%D0%B0&diff=77306Одиннадцатая платформа2023-12-28T22:07:25Z<p>ArsenyMaslennikov: /* Версии подсистем и пакетов */</p>
<hr />
<div>{{Stub}}<br />
<br />
[[Категория:Branches]]<br />
[[Категория:Миграция]]<br />
<br />
Одиннадцатая платформа p11 (), новая стабильная ветка [[branches|репозиториев ALT]], созданная и развиваемая командой ALT ([[ALT Linux Team]]) в рамках проекта [[Sisyphus]], предназначена для разработки, тестирования, распространения, обновления и поддержки комплексных решений всех уровней — от встроенных устройств до серверов предприятий и датацентров. Одиннадцатая платформа будет поддерживаться [[Компания «Базальт СПО»|ООО «Базальт СПО»]].<br />
<br />
__TOC__<br />
<div id="whatsnew"></div><br />
== Что нового? ==<br />
<br />
На отдельной странице описаны нововведения с точки зрения [[Branches/p11/TechnicalNotes|продвинутых пользователей и администраторов]].<br />
<br />
=== Архитектуры Одиннадцатой платформы ===<br />
<br />
Синхронная сборка p11 производится для двух основных [[ports|архитектур]]:<br />
<br />
* 64-битных:<br />
** x86_64;<br />
** aarch64.<br />
<br />
Статус 32-битной i586 уточняется, но в репозитории для x86_64 сохранится поддержка multilib.<br />
<br />
Для 32-битных архитектур <tt>mipsel</tt>, <tt>armh</tt> (armv7a), 64-битной <tt>ppc64le</tt> бранч p11 не создаётся.<br />
<br />
Производится также сборка для трёх версий закрытой 64-битной [[эльбрус/архитектура|архитектуры "Эльбрус"]]:<br />
<br />
* e2k (v3, 4С) и e2kv4 (8С/1С+);<br />
* e2kv5 (8СВ), новой e2kv6.<br />
<br />
{{Todo|&nbsp;}}<br />
<br />
== Версии подсистем и пакетов ==<br />
Репозитории одиннадцатой платформы будут обновляться в течение срока поддержки. На момент официального анонса '''p11''' они содержат в том числе:<br />
<br />
{|class="standard"<br />
!ПО<br />
!Версия<br />
|-<br />
|Ядро Linux (std-def)||6.1.69<br />
|-<br />
|Ядро Linux (un-def)||6.7.2<br />
|-<br />
|Ядро Linux ([[OpenVZ|ovz-el7]])||???<br />
|-<br />
|[[systemd]]||254.1<br />
|-<br />
|GNU libc||2.38<br />
|-<br />
|GCC||13.1.1<br />
|-<br />
|LLVM||16.0, 17.0<br />
|-<br />
|Python||3.12.0 и 2.7.18<br />
|-<br />
|Perl||5.38.2<br />
|-<br />
|PHP||8.3<br />
|-<br />
|Ruby||2.7.3<br />
|-<br />
|Java||11.0.9.11<br />
|-<br />
|Mono||6.12.0.122<br />
|-<br />
|.NET Core||6.0<br />
|-<br />
|Node||14.17.2<br />
|-<br />
|X.Org Server||21.1.8<br />
|-<br />
|Mesa||23.2.0<br />
|-<br />
|[[GNOME]]||45<br />
|-<br />
|[[KDE]]||5.84.0<br />
|-<br />
|[[MATE]]||1.24.1<br />
|-<br />
|[[Xfce]]||4.16.0<br />
|-<br />
|[[Enlightenment]]||0.24.2<br />
|-<br />
|[[Cinnamon]]||5.0.3<br />
|-<br />
|Firefox||120.0, {{pkg|firefox-esr}} 115.6<br />
|-<br />
|LibreOffice||7.6.4.1, {{pkg|LibreOffice-still}} 7.5.9.2<br />
|-<br />
|[[Samba]]||4.19.3 (с [[SambaDC|samba-dc]])<br />
|-<br />
|Bash||5.2.15<br />
|-<br />
|[[BIND]]||9.18.19<br />
|-<br />
|CUPS||2.3.3<br />
|-<br />
|Kea DHCP||4.4.2<br />
|-<br />
|Apache httpd||2.4.48<br />
|-<br />
|nginx||1.24.1<br />
|-<br />
|MariaDB||10.4.20<br />
|-<br />
|PostgreSQL||12.17, 13.13, 14.10, 15.5, 16.1; 12.6 для [[1C]]<br />
|-<br />
|Postfix||3.8.3<br />
|-<br />
|Dovecot||2.3.14<br />
|-<br />
|[[SOGo]]||5.1.1<br />
|-<br />
|OpenSSL||3.1.1<br />
|-<br />
|GTK+||3.24.39, 4.12.4<br />
|-<br />
|Qt||5.15.2<br />
|-<br />
|Tomcat||9.0.45<br />
|-<br />
|[[Docker]]||24.0.7<br />
|-<br />
|[[PVE|Proxmox]]||6.3.3<br />
|-<br />
|[[Kubernetes]]||1.20.8<br />
|-<br />
|[[OpenNebula]]||5.10.5<br />
|-<br />
|[[Ansible]]||2.9.24<br />
|-<br />
|[[Puppet]]||7.9.0<br />
|}<br />
<br />
Состав и версии других пакетов можно посмотреть на сайте [http://packages.altlinux.org/ru/p11/home/ packages.altlinux.org].<br />
<br />
[[Категория:Одиннадцатая платформа]]<br />
<br />
{{Category navigation|title=Одиннадцатая платформа|category=Одиннадцатая платформа}}</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=%D0%9E%D0%B4%D0%B8%D0%BD%D0%BD%D0%B0%D0%B4%D1%86%D0%B0%D1%82%D0%B0%D1%8F_%D0%BF%D0%BB%D0%B0%D1%82%D1%84%D0%BE%D1%80%D0%BC%D0%B0&diff=77304Одиннадцатая платформа2023-12-28T16:20:50Z<p>ArsenyMaslennikov: /* Версии подсистем и пакетов */</p>
<hr />
<div>{{Stub}}<br />
<br />
[[Категория:Branches]]<br />
[[Категория:Миграция]]<br />
<br />
Одиннадцатая платформа p11 (), новая стабильная ветка [[branches|репозиториев ALT]], созданная и развиваемая командой ALT ([[ALT Linux Team]]) в рамках проекта [[Sisyphus]], предназначена для разработки, тестирования, распространения, обновления и поддержки комплексных решений всех уровней — от встроенных устройств до серверов предприятий и датацентров. Одиннадцатая платформа будет поддерживаться [[Компания «Базальт СПО»|ООО «Базальт СПО»]].<br />
<br />
__TOC__<br />
<div id="whatsnew"></div><br />
== Что нового? ==<br />
<br />
На отдельной странице описаны нововведения с точки зрения [[Branches/p11/TechnicalNotes|продвинутых пользователей и администраторов]].<br />
<br />
=== Архитектуры Одиннадцатой платформы ===<br />
<br />
Синхронная сборка p11 производится для двух основных [[ports|архитектур]]:<br />
<br />
* 64-битных:<br />
** x86_64;<br />
** aarch64.<br />
<br />
Статус 32-битной i586 уточняется, но в репозитории для x86_64 сохранится поддержка multilib.<br />
<br />
Для 32-битных архитектур <tt>mipsel</tt>, <tt>armh</tt> (armv7a), 64-битной <tt>ppc64le</tt> бранч p11 не создаётся.<br />
<br />
Производится также сборка для трёх версий закрытой 64-битной [[эльбрус/архитектура|архитектуры "Эльбрус"]]:<br />
<br />
* e2k (v3, 4С) и e2kv4 (8С/1С+);<br />
* e2kv5 (8СВ), новой e2kv6.<br />
<br />
{{Todo|&nbsp;}}<br />
<br />
== Версии подсистем и пакетов ==<br />
Репозитории одиннадцатой платформы будут обновляться в течение срока поддержки. На момент официального анонса '''p11''' они содержат в том числе:<br />
<br />
{|class="standard"<br />
!ПО<br />
!Версия<br />
|-<br />
|Ядро Linux (std-def)||6.1.69<br />
|-<br />
|Ядро Linux (un-def)||6.7.2<br />
|-<br />
|Ядро Linux ([[OpenVZ|ovz-el7]])||???<br />
|-<br />
|[[systemd]]||254.1<br />
|-<br />
|GNU libc||2.38<br />
|-<br />
|GCC||13.1.1<br />
|-<br />
|LLVM||16.0, 17.0<br />
|-<br />
|Python||3.12.0 и 2.7.18<br />
|-<br />
|Perl||5.38.2<br />
|-<br />
|PHP||8.3<br />
|-<br />
|Ruby||2.7.3<br />
|-<br />
|Java||11.0.9.11<br />
|-<br />
|Mono||6.12.0.122<br />
|-<br />
|.NET Core||6.0<br />
|-<br />
|Node||14.17.2<br />
|-<br />
|X.Org Server||21.1.8<br />
|-<br />
|Mesa||23.2.0<br />
|-<br />
|[[GNOME]]||45<br />
|-<br />
|[[KDE]]||5.84.0<br />
|-<br />
|[[MATE]]||1.24.1<br />
|-<br />
|[[Xfce]]||4.16.0<br />
|-<br />
|[[Enlightenment]]||0.24.2<br />
|-<br />
|[[Cinnamon]]||5.0.3<br />
|-<br />
|Firefox||120.0, {{pkg|firefox-esr}} 115.6<br />
|-<br />
|LibreOffice||7.6.4.1, {{pkg|LibreOffice-still}} 7.5.9.2<br />
|-<br />
|[[Samba]]||4.14.6 (с [[SambaDC|samba-dc]])<br />
|-<br />
|Bash||5.2.15<br />
|-<br />
|[[BIND]]||9.18.19<br />
|-<br />
|CUPS||2.3.3<br />
|-<br />
|Kea DHCP||4.4.2<br />
|-<br />
|Apache httpd||2.4.48<br />
|-<br />
|nginx||1.24.1<br />
|-<br />
|MariaDB||10.4.20<br />
|-<br />
|PostgreSQL||12.17, 13.13, 14.10, 15.5, 16.1; 12.6 для [[1C]]<br />
|-<br />
|Postfix||3.8.3<br />
|-<br />
|Dovecot||2.3.14<br />
|-<br />
|[[SOGo]]||5.1.1<br />
|-<br />
|OpenSSL||3.1.1<br />
|-<br />
|GTK+||3.24.39, 4.12.4<br />
|-<br />
|Qt||5.15.2<br />
|-<br />
|Tomcat||9.0.45<br />
|-<br />
|[[Docker]]||24.0.7<br />
|-<br />
|[[PVE|Proxmox]]||6.3.3<br />
|-<br />
|[[Kubernetes]]||1.20.8<br />
|-<br />
|[[OpenNebula]]||5.10.5<br />
|-<br />
|[[Ansible]]||2.9.24<br />
|-<br />
|[[Puppet]]||7.9.0<br />
|}<br />
<br />
Состав и версии других пакетов можно посмотреть на сайте [http://packages.altlinux.org/ru/p11/home/ packages.altlinux.org].<br />
<br />
[[Категория:Одиннадцатая платформа]]<br />
<br />
{{Category navigation|title=Одиннадцатая платформа|category=Одиннадцатая платформа}}</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=%D0%9E%D0%B4%D0%B8%D0%BD%D0%BD%D0%B0%D0%B4%D1%86%D0%B0%D1%82%D0%B0%D1%8F_%D0%BF%D0%BB%D0%B0%D1%82%D1%84%D0%BE%D1%80%D0%BC%D0%B0&diff=77302Одиннадцатая платформа2023-12-28T16:16:31Z<p>ArsenyMaslennikov: /* Версии подсистем и пакетов */</p>
<hr />
<div>{{Stub}}<br />
<br />
[[Категория:Branches]]<br />
[[Категория:Миграция]]<br />
<br />
Одиннадцатая платформа p11 (), новая стабильная ветка [[branches|репозиториев ALT]], созданная и развиваемая командой ALT ([[ALT Linux Team]]) в рамках проекта [[Sisyphus]], предназначена для разработки, тестирования, распространения, обновления и поддержки комплексных решений всех уровней — от встроенных устройств до серверов предприятий и датацентров. Одиннадцатая платформа будет поддерживаться [[Компания «Базальт СПО»|ООО «Базальт СПО»]].<br />
<br />
__TOC__<br />
<div id="whatsnew"></div><br />
== Что нового? ==<br />
<br />
На отдельной странице описаны нововведения с точки зрения [[Branches/p11/TechnicalNotes|продвинутых пользователей и администраторов]].<br />
<br />
=== Архитектуры Одиннадцатой платформы ===<br />
<br />
Синхронная сборка p11 производится для двух основных [[ports|архитектур]]:<br />
<br />
* 64-битных:<br />
** x86_64;<br />
** aarch64.<br />
<br />
Статус 32-битной i586 уточняется, но в репозитории для x86_64 сохранится поддержка multilib.<br />
<br />
Для 32-битных архитектур <tt>mipsel</tt>, <tt>armh</tt> (armv7a), 64-битной <tt>ppc64le</tt> бранч p11 не создаётся.<br />
<br />
Производится также сборка для трёх версий закрытой 64-битной [[эльбрус/архитектура|архитектуры "Эльбрус"]]:<br />
<br />
* e2k (v3, 4С) и e2kv4 (8С/1С+);<br />
* e2kv5 (8СВ), новой e2kv6.<br />
<br />
{{Todo|&nbsp;}}<br />
<br />
== Версии подсистем и пакетов ==<br />
Репозитории одиннадцатой платформы будут обновляться в течение срока поддержки. На момент официального анонса '''p11''' они содержат в том числе:<br />
<br />
{|class="standard"<br />
!ПО<br />
!Версия<br />
|-<br />
|Ядро Linux (std-def)||6.1.69<br />
|-<br />
|Ядро Linux (un-def)||6.7.2<br />
|-<br />
|Ядро Linux ([[OpenVZ|ovz-el7]])||???<br />
|-<br />
|[[systemd]]||254.1<br />
|-<br />
|GNU libc||2.38<br />
|-<br />
|GCC||13.1.1<br />
|-<br />
|LLVM||16.0, 17.0<br />
|-<br />
|Python||3.12.0 и 2.7.18<br />
|-<br />
|Perl||5.34.1<br />
|-<br />
|PHP||8.2<br />
|-<br />
|Ruby||2.7.3<br />
|-<br />
|Java||11.0.9.11<br />
|-<br />
|Mono||6.12.0.122<br />
|-<br />
|.NET Core||6.0<br />
|-<br />
|Node||14.17.2<br />
|-<br />
|X.Org Server||21.1.8<br />
|-<br />
|Mesa||23.2.0<br />
|-<br />
|[[GNOME]]||45<br />
|-<br />
|[[KDE]]||5.84.0<br />
|-<br />
|[[MATE]]||1.24.1<br />
|-<br />
|[[Xfce]]||4.16.0<br />
|-<br />
|[[Enlightenment]]||0.24.2<br />
|-<br />
|[[Cinnamon]]||5.0.3<br />
|-<br />
|Firefox||120.0, {{pkg|firefox-esr}} 115.6<br />
|-<br />
|LibreOffice||7.6.4.1, {{pkg|LibreOffice-still}} 7.5.9.2<br />
|-<br />
|[[Samba]]||4.14.6 (с [[SambaDC|samba-dc]])<br />
|-<br />
|Bash||5.2.15<br />
|-<br />
|[[BIND]]||9.18.19<br />
|-<br />
|CUPS||2.3.3<br />
|-<br />
|Kea DHCP||4.4.2<br />
|-<br />
|Apache httpd||2.4.48<br />
|-<br />
|nginx||1.24.1<br />
|-<br />
|MariaDB||10.4.20<br />
|-<br />
|PostgreSQL||13.3, 12.6 для [[1C]]<br />
|-<br />
|Postfix||3.8.3<br />
|-<br />
|Dovecot||2.3.14<br />
|-<br />
|[[SOGo]]||5.1.1<br />
|-<br />
|OpenSSL||3.1.1<br />
|-<br />
|GTK+||3.24.39, 4.12.4<br />
|-<br />
|Qt||5.15.2<br />
|-<br />
|Tomcat||9.0.45<br />
|-<br />
|[[Docker]]||24.0.7<br />
|-<br />
|[[PVE|Proxmox]]||6.3.3<br />
|-<br />
|[[Kubernetes]]||1.20.8<br />
|-<br />
|[[OpenNebula]]||5.10.5<br />
|-<br />
|[[Ansible]]||2.9.24<br />
|-<br />
|[[Puppet]]||7.9.0<br />
|}<br />
<br />
Состав и версии других пакетов можно посмотреть на сайте [http://packages.altlinux.org/ru/p11/home/ packages.altlinux.org].<br />
<br />
[[Категория:Одиннадцатая платформа]]<br />
<br />
{{Category navigation|title=Одиннадцатая платформа|category=Одиннадцатая платформа}}</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=Usrmerge&diff=77293Usrmerge2023-12-26T14:18:32Z<p>ArsenyMaslennikov: systemd 255 is out</p>
<hr />
<div>[[Категория:Sisyphus]]<br />
<br />
= Usrmerge =<br />
'''''Точный план действий сейчас вырабатывается, и его подробности могут измениться.'''''<br />
Статус воплощения отслеживается в {{altbug|46738}}.<br />
<br />
== Введение ==<br />
Исторически<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|/}}, содержащего все эти подкаталоги.<br />
<br />
Позже, с увеличением средних размеров устройств хранения в машинах, сторонники разделения придумали другие обоснования (например, возможность из окружения в {{path|/{bin,sbin,libX,...}/}} починить немонтирующуюся {{path|/usr}}). Но на сегодняшний день непонятно, какой набор утилит и нужных им so/иных файлов стоит признать частью "системы спасения", которая должна быть доступна без {{path|/usr}}, а какой — нет, ибо сами утилиты приобретают универсальный вид и широкие границы применимости. С развитием механизмов initramfs и живых загрузочных/установочных носителей, а также практикой "раздела восстановления" на локальном хранилище машины среди настольных дистрибутивов этот аргумент теряет всякий смысл.<br />
<br />
Чем сохранять бесцельно дублирующие друг друга два класса мест для одних и тех же файлов, лучше оставить один из них, а другой устранить:<br />
* либо переложить {{path|/usr/{bin,sbin,lib,libx32,lib64,libexec,local,share,src,...}}} в корень,<br />
* либо поместить аналоги этих каталогов из {{path|/}} в {{path|/usr}}.<br />
<br />
Из двух вариантов, входящих в рамки FHS<ref>[https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf]</ref>, второй лучше хотя бы тем, что уменьшает количество top-level каталогов, куда упаковывается постоянное содержимое пакетов, до одного. Сейчас среди FHS-совместимых дистрибутивов это типичный подход, на который в том числе потихоньку начинают полагаться апстримы прикладных пакетов.<br />
<br />
== Rationale ==<br />
* Один каталог (пусть с не очень удачным именем {{path|/usr}}) как объект манипуляции и как общий носитель фиксированного содержимого пакетов удобнее россыпи каталогов, полный список которых даже невозможно построить. Появляется даже смысл рассматривать его в виде отдельной точки монтирования, которую можно держать общей на многих машинах под общим управлением.<br />
** Один каталог легче снапшотить, по нему легче гонять {{cmd|find}}, ...<br />
* Упаковка всего пакетного содержимого в {{path|/usr}} открывает дорогу к виртуальному {{path|/}}, который не находится на устройстве хранения и содержит только пустые каталоги-точки-монтирования.<br />
* Возникает осмысленное разделение между {{path|/usr}}, {{path|/var}} и {{path|/etc}}: первый каталог несёт в себе постоянное содержимое пакетов, не предназначенное к ручной модификации (не через пакетную систему или доставку образа), а другие два уже исторически применяются для переменного хранимого состояния и общесистемных конфигов.<br />
* Сборочным скриптам и прочим интеграционным программным компонентам не нужно будет перебирать каталоги, в которых находится искомая программа.<ref>Вообще-то для этого нужно ещё провести слияние sbin и bin, но оно не несёт срочности и не рассматривается на этой странице.</ref><br />
* Начиная с версии 255, выпущенной в декабре 2023, {{pkg|systemd}} [https://lists.freedesktop.org/archives/systemd-devel/2022-April/047673.html прекратит] поддержку split-usr и unmerged-usr; вот [https://github.com/systemd/systemd/pull/27999/commits/cedcd0bc61913db1e37e19f00d3f97fc72436728 коммит].<br />
** Из кода проекта {{pkg|systemd}}, помимо прочего, исчезнут все упоминания старых каталогов; например, директива <tt>ProtectKernelModules=</tt> больше не будет монтировать заглушку поверх <tt>/lib/modules</tt>, и т. п.<br />
<br />
== Proposed changes ==<br />
Необходимые действия можно разбить на две стадии.<br />
<br />
=== Стадия 1 ===<br />
* На стадии brp завершаться с ошибкой, если обнаружены разные файлы в {{path|/bin/x}} и {{path|/usr/bin/x}}, ...<br />
<br />
1. Определить, что слиянию с аналогами внутри /usr подлежат следующие каталоги:<br />
<pre><br />
/bin<br />
/lib<br />
/lib32<br />
/lib64<br />
/libx32<br />
/sbin<br />
</pre><br />
На каждой машине есть некоторые каталоги из этого списка; они и будут перенесены.<br />
<br />
2. Тем или иным образом научить rpm создавать симлинк вида<br />
<pre><br />
/bin/x -> ../usr/bin/x<br />
</pre><br />
..., если в пакете существует {{path|/usr/bin/x}} и <tt>Provides: /bin/x</tt>. Аналогично для всех каталогов из списка 1. Таким образом, на переходном этапе будет не нужно указывать в <tt>%files</tt> пакетов все эти симлинки, чтобы потом их убирать, и пакеты продолжат удовлетворять зависимостям на такие файлы.<br />
<br />
Важно, чтобы сначала удалялся старый путь, как обычно при установке<br />
пакета, а симлинк возникал после этой фазы.<br />
<br />
2.1) Бекпортировать поддержку в p10.<br />
<br />
3) Подготовить пакет {{pkg|filesystem}} версии 3: поместить в нём файлтриггер,<br />
который проверяет, не состоят ли каталоги из списка 1 целиком из<br />
симлинков внутрь {{path|/usr}}, и превращает такой каталог с симлинками в симлинк<br />
на каталог.<br />
Сценарий файлтриггера должен будет давать предельно ясную информацию и<br />
диагностические сообщения на стандартные потоки. Нужно будет либо<br />
положиться на static coreutils, либо очень осторожно обращаться с<br />
обычными и dynamic linker.<br />
<br />
4) Заменить макросы, использующие старые каталоги (<tt>%_udevrulesdir</tt>,<br />
<tt>%_tmpfilesdir</tt> и другие), и пересобрать с ними пакеты, что-либо<br />
помещающие в эти каталоги.<br />
Приближённое число затрагиваемых бинарных пакетов:<br />
<pre><br />
% grep -E '^/(bin|lib[^/]*|sbin)/[a-z0-9_-]+' contents-index \<br />
| grep -vE '^/lib/(systemd|udev|sysusers.d|modules[^/]*|modprobe.d|security|tmpfiles.d)'<br />
\ # exclude known places<br />
| cut -f2 -d$'\t' | grep -v '^/' # exclude path provides<br />
| sort | uniq | wc -l<br />
528<br />
</pre><br />
Это оценка по x86_64 + noarch. Исходных, конечно, будет меньше.<br />
<br />
При обновлении на эти пакеты будет действовать правило 2, поэтому их<br />
содержимое будет доступно.<br />
<br />
Некоторые пакеты, например, {{pkg|vim-common}}, сейчас упаковывают разные<br />
файловые объекты в {{path|/bin}} и {{path|/usr/bin}}; другие пакеты ставят файлы прямо<br />
в {{path|%buildroot/bin}}. Их потребуется исправить руками. (Справедливости ради,<br />
многие из них и так понадобится обновить)<br />
<br />
=== Стадия 2 ===<br />
Этот пункт вступает в действие на каждой машине индивидуально при<br />
обновлении её пакетов.<br />
Файлтриггер из пункта 3 обнаруживает, что можно ввести симлинки, и<br />
делает это, завершая процесс usrmerge на данной системе.<br />
<br />
Каждая инсталляция перейдёт к ней независимо, как только все пакеты в этой инсталляции будут содержать свои файлы под {{path|/usr}}.<br />
<br />
== Incompatibilities ==<br />
<br />
Если корневая файловая система — каскадная композиция на базе, например, overlayfs, и каталоги {{path|/bin}} и подобные находятся ''не в верхнем'' слое стека — автоматически обновить такую корневую файловую систему на {{pkg|filesystem > 3}} '''не выйдет'''. Придётся либо не обновляться, либо пересобрать контейнер/систему на обновлённой пакетной базе.<br />
<br />
== FAQ ==<br />
<br />
Рекомендуем прочитать другие материалы о преимуществах предлагаемого решения<ref>[https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ TheCaseForTheUsrMerge]</ref><ref>[https://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/ separate-usr-is-broken], примеры, где в ранней системе полагаются на наличие {{path|/usr}}}</ref>.<br />
<br />
'''Q: А что, если {{path|/usr}} на отдельном разделе по каким-то причинам не примонтируется?'''<br />
<br />
A: Тогда система не сможет загрузиться, как и в случае, если {{path|/}} по каким-то причинам не примонтируется.<br />
<br />
'''Q: А раньше можно было, пользуясь программами в {{path|/}}, починить {{path|/usr}}'''<br />
<br />
A: Несколько тезисов:<br />
* В-нулевых, для того, чтобы возникла такая ситуация, систему должны были установить так, чтобы {{path|/usr}} был отдельным от {{path|/}}, т. е. такая разметка преследовала какую-либо цель.<br />
* Во-первых, для этого нужно, чтобы {{path|/}} '''смог''' смонтироваться, а {{path|/usr}} '''не смог'''.<br />
* Во-вторых, всё ещё нет критерия, по которому ту или иную программу и её зависимости можно либо отнести к "системе спасения", либо исключить из неё и сослать в {{path|/usr}}.<br />
* В-третьих, нет ни одного задокументированного случая, где таким образом спасли какую-либо типичную GNU/Linux-систему, включая Альт, есть только [https://www.ecb.torontomu.ca/~elf/hack/recovery.html предание] из 1986 года, касавшееся non-Linux тех времён на компьютере тех времён. Рецептов такого восстановления, отчуждаемых от компетенций разработчиков ALT и умелых сисадминов, нет тем более. Следовательно, можно заключить, что в общем случае цитируемая возможность восстановить {{path|/usr}} из {{path|/}} — призрачна.<br />
* Несмотря на всё это, нет ничего плохого в том, чтобы рецепт такого спасения (при помощи операционной избыточности инсталляции альта) администратору ''предложить'', но это должен быть явный механизм с минимумом издержек для остальной структуры системы. Есть множество вариантов это реализовать с разными преимуществами и минусами в разных установках; все они out of scope for this document.<br />
<br />
== User-visible impact ==<br />
Меньше каталогов верхнего уровня в корне, кроме симлинков.<br />
<br />
== Appendix ==</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=NobodySubjectPolicy&diff=76956NobodySubjectPolicy2023-12-09T22:09:47Z<p>ArsenyMaslennikov: /* FAQ */</p>
<hr />
<div>{{DraftPolicy<br />
|responsible=arseny@<br />
|discussion_link=https://lore.altlinux.org/devel/ZVTBCLVCmMnpMpJ6@cello/t/#u<br />
|discussion_since=2023-11-15<br />
}}<br />
<br />
== Введение ==<br />
Как известно, в файле {{term|passwd}} по умолчанию в наших системах присутствуют пользователь и группа {{term|nobody}}.<br />
<br />
Одно время в кругу разработчиков и администраторов ходила мода считать этого пользователя "наименее привилегированным", будто ему почти ничего нельзя: в ФС почти нет файлов, ему доступных, у него нет логин-шелла, под ним нельзя запустить десктоп штатными средствами, и т. д.<br />
Из этого выводили ошибочное следствие, что какой-нибудь нетребовательный процесс-службу можно запускать прямо под {{term|nobody}}, чтобы отсечь ему доступ к "более важным" службам.<br />
Как только таких сервисов становится больше одного, оказывается, что все они работают с общими привилегиями, могут слать друг другу сигналы и т. д., то есть недостаточно изолированы друг от друга.<br />
Им просто следует работать под собственными системными UID, а концепция "наименее привилегированного uid" не имеет смысла.<br />
<br />
В [[Kernel|ядре Linux]] достаточно давно есть [https://docs.kernel.org/admin-guide/sysctl/fs.html#overflowgid-overflowuid понятие] {{term|overflowuid}}/{{term|overflowgid}}:<br />
зарезервированное значение uid и gid, которое используется, чтобы обозначить в одной подсистеме непредставимые значения uid и gid в файлах из другой подсистемы.<br />
Например, в файловых системах с 16-разрядными полями uid и gid вместо невлезающего значения будет записан {{term|overflowuid}}/{{term|overflowgid}}.<br />
Другой пример: NFS-клиент может представлять рута на клиентской машине {{term|overflowuid}}ом на сервере.<br />
Ныне разнородные апстримы сходятся на том, чтобы зафиксировать в качестве этого значения число <tt>((uint16_t)-2)</tt>, оно же <tt>65534</tt>, дефолт в ядре, и обозвать этого пользователя {{term|nobody}}. Тем самым они ''объединяют'' понятия {{term|nobody}} и {{term|overflow[ug]id}}.<br />
<br />
Вообще говоря, под пользователем {{term|nobody}} и группой {{term|nobody}} в системе не должно работать ничего, а в ФС на несъёмных устройствах хранения не должно создаваться файловых объектов с такими uid и gid.<br />
Для того, чтобы это гарантировать, следует ввести автоматические проверки хотя бы на этапе сборки пакетов.<ref>А лучше даже во время работы системы (что-то вроде seccomp-фильтра на всех процессах, запрещающего setuid и setgid в этого пользователя), но это более сложная задача, решения которой на ванильном ядре могут оказаться сверхнеэффективными.</ref><br />
<br />
== Нормативные предписания ==<br />
<small>Здесь и далее словосочетание "под {{term|nobody}}" сохраняет свой общепринятый смысл, но относится и к uid, и к основному gid.</small><br />
* В пакеты '''запрещается''' помещать файловые объекты под {{term|nobody}}. Исполнение правила контролирует sisyphus-check;<br />
* Мейнтейнеры не должны допускать, чтобы собираемые ими системные службы исполняли код под {{term|nobody}} или имели {{term|nobody}} в числе дополнительных (''supplementary'') групп. Исполнение правила призван гарантировать brp-скрипт при сборке пакета;<br />
* Администраторам систем на базе Альт рекомендуется не запускать процессы под пользователем и группой {{term|nobody}} или помещать {{term|nobody}} в число дополнительных (''supplementary'') групп.<br />
<br />
== FAQ ==<br />
'''Q:''' Что будет, если записать на флешку файлы с uid/gid 65534 и подключить её к системе?<br />
<br />
'''A:''' Система воспримет такие файлы как файлы с непонятным uid/gid. Эти uid/gid нет смысла, например, сравнивать с другими и (что важно) друг с другом. Процесс с {{term|CAP_DAC_OVERRIDE}} и т. п., как обычно, сможет сделать с ними всё, что угодно.<br />
<br />
== Примечания ==</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=NobodySubjectPolicy&diff=76794NobodySubjectPolicy2023-11-30T23:49:37Z<p>ArsenyMaslennikov: Добавил ненормативную секцию FAQ</p>
<hr />
<div>{{DraftPolicy<br />
|responsible=arseny@<br />
|discussion_link=https://lore.altlinux.org/devel/ZVTBCLVCmMnpMpJ6@cello/t/#u<br />
|discussion_since=2023-11-15<br />
}}<br />
<br />
== Введение ==<br />
Как известно, в файле {{term|passwd}} по умолчанию в наших системах присутствуют пользователь и группа {{term|nobody}}.<br />
<br />
Одно время в кругу разработчиков и администраторов ходила мода считать этого пользователя "наименее привилегированным", будто ему почти ничего нельзя: в ФС почти нет файлов, ему доступных, у него нет логин-шелла, под ним нельзя запустить десктоп штатными средствами, и т. д.<br />
Из этого выводили ошибочное следствие, что какой-нибудь нетребовательный процесс-службу можно запускать прямо под {{term|nobody}}, чтобы отсечь ему доступ к "более важным" службам.<br />
Как только таких сервисов становится больше одного, оказывается, что все они работают с общими привилегиями, могут слать друг другу сигналы и т. д., то есть недостаточно изолированы друг от друга.<br />
Им просто следует работать под собственными системными UID, а концепция "наименее привилегированного uid" не имеет смысла.<br />
<br />
В [[Kernel|ядре Linux]] достаточно давно есть [https://docs.kernel.org/admin-guide/sysctl/fs.html#overflowgid-overflowuid понятие] {{term|overflowuid}}/{{term|overflowgid}}:<br />
зарезервированное значение uid и gid, которое используется, чтобы обозначить в одной подсистеме непредставимые значения uid и gid в файлах из другой подсистемы.<br />
Например, в файловых системах с 16-разрядными полями uid и gid вместо невлезающего значения будет записан {{term|overflowuid}}/{{term|overflowgid}}.<br />
Другой пример: NFS-клиент может представлять рута на клиентской машине {{term|overflowuid}}ом на сервере.<br />
Ныне разнородные апстримы сходятся на том, чтобы зафиксировать в качестве этого значения число <tt>((uint16_t)-2)</tt>, оно же <tt>65534</tt>, дефолт в ядре, и обозвать этого пользователя {{term|nobody}}. Тем самым они ''объединяют'' понятия {{term|nobody}} и {{term|overflow[ug]id}}.<br />
<br />
Вообще говоря, под пользователем {{term|nobody}} и группой {{term|nobody}} в системе не должно работать ничего, а в ФС на несъёмных устройствах хранения не должно создаваться файловых объектов с такими uid и gid.<br />
Для того, чтобы это гарантировать, следует ввести автоматические проверки хотя бы на этапе сборки пакетов.<ref>А лучше даже во время работы системы (что-то вроде seccomp-фильтра на всех процессах, запрещающего setuid и setgid в этого пользователя), но это более сложная задача, решения которой на ванильном ядре могут оказаться сверхнеэффективными.</ref><br />
<br />
== Нормативные предписания ==<br />
<small>Здесь и далее словосочетание "под {{term|nobody}}" сохраняет свой общепринятый смысл, но относится и к uid, и к основному gid.</small><br />
* В пакеты '''запрещается''' помещать файловые объекты под {{term|nobody}}. Исполнение правила контролирует sisyphus-check;<br />
* Мейнтейнеры не должны допускать, чтобы собираемые ими системные службы исполняли код под {{term|nobody}} или имели {{term|nobody}} в числе дополнительных (''supplementary'') групп. Исполнение правила призван гарантировать brp-скрипт при сборке пакета;<br />
* Администраторам систем на базе Альт рекомендуется не запускать процессы под пользователем и группой {{term|nobody}} или помещать {{term|nobody}} в число дополнительных (''supplementary'') групп.<br />
<br />
== FAQ ==<br />
'''Q:''' Что будет, если записать на флешку файлы с uid/gid 65534 и подключить её к системе?<br />
<br />
'''A:''' Система воспримет такие файлы как файлы с непонятным uid/gid. Эти uid/gid нет смысла, например, сравнивать с другими и (что важно) друг с другом. Процесс с {term|CAP_DAC_OVERRIDE} и т. п., как обычно, сможет сделать с ними всё, что угодно.<br />
<br />
== Примечания ==</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=NobodySubjectPolicy&diff=76793NobodySubjectPolicy2023-11-30T23:42:27Z<p>ArsenyMaslennikov: /* Нормативные предписания */ Уточнили, что в brp будут проверки юнитов</p>
<hr />
<div>{{DraftPolicy<br />
|responsible=arseny@<br />
|discussion_link=https://lore.altlinux.org/devel/ZVTBCLVCmMnpMpJ6@cello/t/#u<br />
|discussion_since=2023-11-15<br />
}}<br />
<br />
== Введение ==<br />
Как известно, в файле {{term|passwd}} по умолчанию в наших системах присутствуют пользователь и группа {{term|nobody}}.<br />
<br />
Одно время в кругу разработчиков и администраторов ходила мода считать этого пользователя "наименее привилегированным", будто ему почти ничего нельзя: в ФС почти нет файлов, ему доступных, у него нет логин-шелла, под ним нельзя запустить десктоп штатными средствами, и т. д.<br />
Из этого выводили ошибочное следствие, что какой-нибудь нетребовательный процесс-службу можно запускать прямо под {{term|nobody}}, чтобы отсечь ему доступ к "более важным" службам.<br />
Как только таких сервисов становится больше одного, оказывается, что все они работают с общими привилегиями, могут слать друг другу сигналы и т. д., то есть недостаточно изолированы друг от друга.<br />
Им просто следует работать под собственными системными UID, а концепция "наименее привилегированного uid" не имеет смысла.<br />
<br />
В [[Kernel|ядре Linux]] достаточно давно есть [https://docs.kernel.org/admin-guide/sysctl/fs.html#overflowgid-overflowuid понятие] {{term|overflowuid}}/{{term|overflowgid}}:<br />
зарезервированное значение uid и gid, которое используется, чтобы обозначить в одной подсистеме непредставимые значения uid и gid в файлах из другой подсистемы.<br />
Например, в файловых системах с 16-разрядными полями uid и gid вместо невлезающего значения будет записан {{term|overflowuid}}/{{term|overflowgid}}.<br />
Другой пример: NFS-клиент может представлять рута на клиентской машине {{term|overflowuid}}ом на сервере.<br />
Ныне разнородные апстримы сходятся на том, чтобы зафиксировать в качестве этого значения число <tt>((uint16_t)-2)</tt>, оно же <tt>65534</tt>, дефолт в ядре, и обозвать этого пользователя {{term|nobody}}. Тем самым они ''объединяют'' понятия {{term|nobody}} и {{term|overflow[ug]id}}.<br />
<br />
Вообще говоря, под пользователем {{term|nobody}} и группой {{term|nobody}} в системе не должно работать ничего, а в ФС на несъёмных устройствах хранения не должно создаваться файловых объектов с такими uid и gid.<br />
Для того, чтобы это гарантировать, следует ввести автоматические проверки хотя бы на этапе сборки пакетов.<ref>А лучше даже во время работы системы (что-то вроде seccomp-фильтра на всех процессах, запрещающего setuid и setgid в этого пользователя), но это более сложная задача, решения которой на ванильном ядре могут оказаться сверхнеэффективными.</ref><br />
<br />
== Нормативные предписания ==<br />
<small>Здесь и далее словосочетание "под {{term|nobody}}" сохраняет свой общепринятый смысл, но относится и к uid, и к основному gid.</small><br />
* В пакеты '''запрещается''' помещать файловые объекты под {{term|nobody}}. Исполнение правила контролирует sisyphus-check;<br />
* Мейнтейнеры не должны допускать, чтобы собираемые ими системные службы исполняли код под {{term|nobody}} или имели {{term|nobody}} в числе дополнительных (''supplementary'') групп. Исполнение правила призван гарантировать brp-скрипт при сборке пакета;<br />
* Администраторам систем на базе Альт рекомендуется не запускать процессы под пользователем и группой {{term|nobody}} или помещать {{term|nobody}} в число дополнительных (''supplementary'') групп.<br />
<br />
== Примечания ==</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=Mantainer_Change_Policy&diff=76771Mantainer Change Policy2023-11-30T13:08:17Z<p>ArsenyMaslennikov: ArsenyMaslennikov переименовал страницу Mantainer Change Policy в Maintainer Change Policy: слова "mantainer" не существует</p>
<hr />
<div>#перенаправление [[Maintainer Change Policy]]</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=Maintainer_Change_Policy&diff=76770Maintainer Change Policy2023-11-30T13:08:16Z<p>ArsenyMaslennikov: ArsenyMaslennikov переименовал страницу Mantainer Change Policy в Maintainer Change Policy: слова "mantainer" не существует</p>
<hr />
<div>{{DraftPolicy<br />
|responsible=?<br />
|discussion_link=...<br />
|discussion_since=...<br />
}}<br />
<br />
== Изменение мейнтейнера пакета ==<br />
<br />
Пакет имеет право быть переданным другому мейнтейнеру в случае выполнения одного из условий:<br />
* отсутствие реакции мейнтейнера на запросы через список рассылки devel@ в течении двух месяцев<br />
* несколько NMU подряд от кандидата в мейнтейнеры<br />
* добровольная передача мейнтейнером пакета с уведомлением в списке рассылки devel@<br />
* переезд пакета в Orphaned по причине несобираемости<br />
<br />
Пакет забирается кандидатом в мейнтейнеры в уведомительном порядке. Уведомление отправляется в список рассылки devel@.</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=Maintainer_Change_Policy&diff=76769Maintainer Change Policy2023-11-30T13:07:12Z<p>ArsenyMaslennikov: maintainers are responsible for lots of things other than man pages</p>
<hr />
<div>{{DraftPolicy<br />
|responsible=?<br />
|discussion_link=...<br />
|discussion_since=...<br />
}}<br />
<br />
== Изменение мейнтейнера пакета ==<br />
<br />
Пакет имеет право быть переданным другому мейнтейнеру в случае выполнения одного из условий:<br />
* отсутствие реакции мейнтейнера на запросы через список рассылки devel@ в течении двух месяцев<br />
* несколько NMU подряд от кандидата в мейнтейнеры<br />
* добровольная передача мейнтейнером пакета с уведомлением в списке рассылки devel@<br />
* переезд пакета в Orphaned по причине несобираемости<br />
<br />
Пакет забирается кандидатом в мейнтейнеры в уведомительном порядке. Уведомление отправляется в список рассылки devel@.</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=CoreSystem/SpecCriticism&diff=76679CoreSystem/SpecCriticism2023-11-26T10:47:03Z<p>ArsenyMaslennikov: /* Зависимость от архитектуры */</p>
<hr />
<div>{{Stub}}<br />
<br />
== Что не так с rpm и спеками ==<br />
<br />
=== Затруднена рефлексия ===<br />
Теги и секции в спеке начинают анализироваться после раскрытия макросов.<br />
Это означает, что о спеке ничего нельзя сказать, не раскрыв рекурсивно все макросы.<br />
Более того, конструкция `%()` раскрывается в результат исполнения произвольного кода на шелле.<br />
Соответственно, из спека в общем случае невозможно что-либо достать, не раскрыв все макросы и не исполнив все встроенные шелльные вставки — включая информацию о версии, релизе и лицензии.<br />
Это затрудняет анализ спеков без необходимости сборки спека, в том числе массовый.<br />
<br />
Стандартные инструменты авторов пакетов ALT Linux Team прибегают к эвристикам для получения этой информации в надежде, что в 95% случаев этого достаточно.<br />
<br />
=== Зависимость от архитектуры ===<br />
В силу того, что язык спеков — макроязык без костей (см. предыдущий параграф), очень легко сделать SRPM (не "бинарный" пакет, а ''исходный''), зависящий от архитектуры: например, [https://lore.altlinux.org/devel/334b9a3d-2242-6ef7-a377-68817f639fb4@altlinux.org/t с разным списком патчей и сурсов] на разных архитектурах. Если, например, собрать такой пакет в репозиторий, то опубликован будет ''один'' из этих srpm, но продуктовые ("бинарные") пакеты будут собраны из srpm, раскрытых в окружении с определённым {{term|%arch}}.<br />
Это стреляет в разных местах: например, на пересборочницу на всех архитектурах попадает общий srpm.</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=CoreSystem/SpecCriticism&diff=76678CoreSystem/SpecCriticism2023-11-26T10:21:09Z<p>ArsenyMaslennikov: Новая страница: «{{Stub}} == Что не так с rpm и спеками == === Затруднена рефлексия === Теги и секции в спеке начинают анализироваться после раскрытия макросов. Это означает, что о спеке ничего нельзя сказать, не раскрыв рекурсивно все макросы. Более того, конструкция `%()` раскрыва...»</p>
<hr />
<div>{{Stub}}<br />
<br />
== Что не так с rpm и спеками ==<br />
<br />
=== Затруднена рефлексия ===<br />
Теги и секции в спеке начинают анализироваться после раскрытия макросов.<br />
Это означает, что о спеке ничего нельзя сказать, не раскрыв рекурсивно все макросы.<br />
Более того, конструкция `%()` раскрывается в результат исполнения произвольного кода на шелле.<br />
Соответственно, из спека в общем случае невозможно что-либо достать, не раскрыв все макросы и не исполнив все встроенные шелльные вставки — включая информацию о версии, релизе и лицензии.<br />
Это затрудняет анализ спеков без необходимости сборки спека, в том числе массовый.<br />
<br />
Стандартные инструменты авторов пакетов ALT Linux Team прибегают к эвристикам для получения этой информации в надежде, что в 95% случаев этого достаточно.<br />
<br />
=== Зависимость от архитектуры ===<br />
В силу того, что язык спеков — макроязык без костей (см. предыдущий параграф), очень легко сделать SRPM (не "бинарный" пакет, а ''исходный''), зависящий от архитектуры. Если, например, собрать такой пакет в репозиторий, то опубликован будет ''один'' из этих srpm, но продуктовые ("бинарные") пакеты будут собраны из srpm, раскрытых в окружении с определённым {{term|%arch}}.</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=CoreSystem/aptrpm/HistoricalDebianConfusion&diff=76673CoreSystem/aptrpm/HistoricalDebianConfusion2023-11-24T23:51:42Z<p>ArsenyMaslennikov: Новая страница: «=== Как нас путают с дебианом === <br/> Николай, https://t.me/alt_linux/336171 24.11.2023 22:14 День добрый! Что насчёт перехода на apt? На странице Федоры прочёл их заключение относительно APT-RPM: However, APT-RPM is unmaintained, broken, and insecure, and so was dropped Ruslandh, https://t.me/alt_linux/336172 24.11.2023 22:14 Значит он...»</p>
<hr />
<div>=== Как нас путают с дебианом ===<br />
<br/><br />
Николай, [[https://t.me/alt_linux/336171 24.11.2023 22:14]]<br />
День добрый!<br />
Что насчёт перехода на apt?<br />
На странице Федоры прочёл их заключение относительно APT-RPM:<br />
However, APT-RPM is unmaintained, broken, and insecure, and so was dropped<br />
<br />
Ruslandh, [[https://t.me/alt_linux/336172 24.11.2023 22:14]]<br />
Значит он у них такой :-)<br />
<br />
Николай, [[https://t.me/alt_linux/336173 24.11.2023 22:14]]<br />
У Альта сказано: утилиты apt в составе пакета apt пока нет;<br />
Хоть приблизительные планы имеются?<br />
<br />
Aleksey Novodvorsky, [[https://t.me/alt_linux/336185 24.11.2023 22:14]]<br />
У нас сврй форк apt-rpm, он развивается самостоятельно и он останется<br />
<br />
Николай, [[https://t.me/alt_linux/336186 24.11.2023 22:14]]<br />
Понял, благодарю вас!<br />
<br />
Сергей, [[https://t.me/alt_linux/336195 24.11.2023 22:14]]<br />
Сдаётся мне, что по набору параметров дебиановский apt и ALT-овый apt-get различаются. Точно есть смысл в алиасе?<br />
<br />
Андрей Черепанов, [[https://t.me/alt_linux/336301 24.11.2023 22:14]]<br />
Нет смысла.<br />
<br />
Николай, [[https://t.me/alt_linux/336182 24.11.2023 22:14]]<br />
Если он insecure и unmaintained, может стоит его поменять на что-то посвежее, а не просто прописывать алиас?<br />
И да, я использую sisyphus и команды apt в нём нет<br />
<br />
Aleksey Novodvorsky, [[https://t.me/alt_linux/336187 24.11.2023 22:14]]<br />
У нас он secure и maintained. Смотрите код<br />
<br />
Сергей, [[https://t.me/alt_linux/336306 24.11.2023 22:14]]<br />
А всё-таки, зачем Вам в ALT нужен apt и с чего Вы решили, что apt-get неподдерживаемый? Вы этот apt-get с дебиановским перепутали? Если да, то напрасно. Общее между ними осталось где-то в 2000 году. По идее альтовский apt-get можно бы и переименовать, если бы это не исторически сложилось.<br />
<br />
Николай, [[https://t.me/alt_linux/336310 24.11.2023 22:14]]<br />
Прочитал про оригинальный apt-rpm, что проект давно заброшен. Сегодня на сайте Федоры наткнулся на его упоминание, вот и спросил<br />
<br />
Сергей, [[https://t.me/alt_linux/336328 24.11.2023 22:14]]<br />
Только в рамках ALT Linux он вовсе не заброшен:<br />
https://git.altlinux.org/gears/a/apt.git?p=apt.git;a=summary<br />
Можете считать апстримом, если хотите.<br />
<br />
Aleksey Novodvorsky, [[https://t.me/alt_linux/336343 24.11.2023 22:14]]<br />
Надо переименовать apt-get и rpm :)<br />
Но это не раньше p12<br />
<br />
</br></div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=CoreSystem/aptrpm&diff=76672CoreSystem/aptrpm2023-11-24T23:46:47Z<p>ArsenyMaslennikov: /* Wishlist */</p>
<hr />
<div>'''Sisyphus Core''' — пакетная система<br />
<br />
<onlyinclude><br />
== Планы по развитию apt/rpm ==<br />
<br />
* введение поддержки бинарных пакетов на zstd payload<br />
** позднее: возможно, пересборка всех бинарных пакетов на zstd payload<br />
* сборка rpm с поддержкой biarch (новой версии, или backport на старую)<br />
<br />
== Wishlist ==<br />
<br />
=== Окружение сборки пакетов ===<br />
* Встраивание в упаковываемые ELF-объекты [https://systemd.io/ELF_PACKAGE_METADATA/ package notes]<br />
<br />
=== Репозитории и тулинг ===<br />
* Связь между пакетами типа "рекомендация" [shaba]<br />
** RPM поддерживает в производных пакетах тег <tt>Recommends:</tt><br />
** Интерактивный install или dist-upgrade предлагает пользователю не 2 варианта, а 3: <tt>Yes</tt>, <tt>Yes with recommends</tt>, <tt>No</tt>. Возможно, поставить это нововведение в зависимость от ключа в <tt>apt.conf</tt> [antohami]<br />
** Если выбран вариант Y и были установлены новые пакеты (далее — мн-во пакетов <tt>K</tt>), по окончании транзакции apt даёт в терминал сжато сформулированное сообщение о к-ве пакетов, "рекомендованных" пакетами из K, и подсказку, как их посмотреть/установить, в виде команды для apt.<br />
<p><br />
Проясним терминологию. Debian policy [https://www.debian.org/doc/debian-policy/ch-relationships.html says]:<br />
<pre><br />
Recommends<br />
<...><br />
The Recommends field should list packages that would be found together with this one in all but unusual installations.<br />
<br />
Suggests<br />
This is used to declare that one package may be more useful with one or more others. Using this field tells the packaging system and the user that the listed packages are related to this one and can perhaps enhance its usefulness, but that installing this one without them is perfectly reasonable.<br />
</pre><br />
</p><br />
* Бекпорт из апстрима тега <tt>RemovePathPostfixes:</tt> [shaba].<br />
<br />
* Быстрый и компактный contents_index (200Mb сейчас, сжимается после cat | sort | lzma до 7.5Mb, умный radix tree должен дать O(logN) время поиска файлов и размер в ~10Mb) [dottedmag, ab]<br />
* Утилита <tt>apt-file</tt>, получающая contents способом, не имеющим недостатков rsync и совместимая с одноимённым интерфейсом из apt. [arseny]<br />
** rsync эффективен по к-ву сетевого трафика, но крайне неэффективен по I/O на устройствах, где хранятся новая и обновляемая копия. На rsync-сервере стоит ожидать I/O thrashing от всех качающих.<br />
* Бекпорт (или реализация заново, чего уж там) в APT поддержки [https://en.wikipedia.org/wiki/Happy_Eyeballs Happy Eyeballs]. Есть запрос от [https://t.me/version6/57180 стеснительных пользователей]. [arseny]<br />
<br />
* apt-zeroconf: поддержка поиска репозиториев в локальной сети при помощи zeroconf [dottedmag, ab]<br />
* Инструмент для создания APT-источник'а и публикации zeroconf-сервиса [dottedmag, ab]. Пакеты берутся из<br />
** CD/DVD-дисков релизов<br />
** CD/DVD-дисков апдейтов<br />
** Регулярных APT-источников<br />
</onlyinclude><br />
<br />
=== Описание процедуры сборки пакетов ===<br />
Для описания недостатков формата spec и предложений по усовершенствованию цепочки "исходники+спек → артефакты" выделена [[CoreSystem/SpecCriticism|отдельная страница]].<br />
<br />
=== UX администратора ===<br />
* Наши инструменты управления источниками пакетов непозволительно часто [[CoreSystem/aptrpm/HistoricalDebianConfusion|путают с дебианом]]. Нужно решиться:<br />
** либо рыбку съесть (спортировать и смёржить apt посвежее, или же озабочиваться совместимостью командного интерфейса с Debian),<br />
** либо не давиться косточкой (обозначиться форком и изменить апту имя).<br />
<br />
{{CoreSystem-nav}}<br />
<br />
[[Категория:RPM]]<br />
[[Категория:APT]]</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=Python_packaging_guide&diff=76670Python packaging guide2023-11-24T20:42:26Z<p>ArsenyMaslennikov: many green tt elements were missing the closing tag</p>
<hr />
<div>[[Файл:Python-logo-master-v3-TM-flattened.png|безрамки|справа]]<br />
==Python packaging guide==<br />
This guide is intended to cover the packaging of Python projects: source trees having legacy '''setup.py''' or modern '''pyproject.toml''' (or both) files.<br />
<br />
A packaging of Python distribution implies two mandatory steps:<br />
* <tt><span style="color:green">build</span></tt> - build some artifact which can be either bare source files or binary distribution also known as [https://packaging.python.org/en/latest/specifications/binary-distribution-format/ wheel]<br />
* <tt><span style="color:green">install</span></tt> - installation of produced build artifact<br />
<br />
There are optional steps as well: <br />
* <tt><span style="color:green">check</span></tt><br />
<br />
<br />
===Build===<br />
<br />
<br />
Python projects can be one of two types:<br />
* <tt><span style="color:green">pure</span></tt> Python distributions which don't require any actual building process and can be just copied/pasted onto destination as is <br />
* <tt><span style="color:green">platform-dependent</span></tt> distributions which require special building process and can't be just copied/pasted onto destination as is <br />
<br />
====Sources====<br />
There are two supported options for sources:<br />
* source tree (snapshot of VCS)<br />
* source distribution also known as [https://packaging.python.org/en/latest/specifications/source-distribution-format/ sdist]<br />
<br />
=====VCS and gear=====<br />
A source tree produced by '''gear''' is not a valid VCS checkout due to missing SCM's internal data (e.g. '''.git''' directory and its content).<br><br />
Some packaging plugins may rely on SCM. For example,<br />
<blockquote><br />
<tt><span style="color:green">setuptools_scm</span></tt> implements a '''file_finders''' entry point which returns all files tracked by your SCM. This eliminates the need for a manually constructed MANIFEST.in in most cases where this would be required when not using setuptools_scm, namely:<br />
* To ensure all relevant files are packaged when running the sdist command.<br />
* When using '''include_package_data''' to include package data as part of the '''build''' or '''bdist_wheel'''.<br />
</blockquote><br />
Thus, actual SCM source tree is required in this case, otherwise some expected data (everything, besides Python packages or modules) may not be packaged.<br><br />
For example, basic git configuration maybe done in RPM specfile with:<br />
<syntaxhighlight lang="console"><br />
if [ ! -d .git ]; then<br />
git init <br />
git config user.email author@example.com <br />
git config user.name author <br />
git add . <br />
git commit -m 'release' <br />
git tag '%version'<br />
fi<br />
</syntaxhighlight><br />
<br />
=====pypi.org=====<br />
Though it's possible to use wheels from pypi.org as source for installation (skipping build step), in general, it's bad idea to just unpack such a wheel for many reasons like:<br />
* wheels may be platform-specific<br />
* wheels are prebuilt distributions, builders of which may not follow distro's build rules and policies, can link to whatever they want and so on<br />
* wheels are usually stripped (there are no tests, docs, etc.)<br />
<br />
Thus, only source distribution can be used from pypi.org for packaging, though it's recommended to use a source of sdist e.g., a code fetched from code hostings. <br />
<br />
====Build roles====<br />
With accepted PEP517 a build process is more standardized and is split into two responsibilities:<br />
* <tt><span style="color:green">build frontend</span></tt> takes arbitrary source tree and calls build backend on them. User can use one frontend for building any PEP517-aware project. <br />
* <tt><span style="color:green">build backend</span></tt> actually builds sdist or wheel. Backend is per-project defined entity. <br />
<br />
====Build dependencies====<br />
With accepted PEP518 the format of static build dependencies is standardized and can be configured in TOML via <tt><span style="color:green">pyproject.toml</span></tt> file.<br />
<br />
For the vast majority of projects the PEP517/518 configuration will be:<br />
<syntaxhighlight lang="TOML"><br />
[build-system]<br />
requires = ["setuptools", "wheel"]<br />
build-backend = "setuptools.build_meta"<br />
</syntaxhighlight><br />
<br />
* distro packager is responsible for specifying these requirements in RPM specfile. Though these dependencies may not be enough since a backend may have dynamic ones. See [https://peps.python.org/pep-0517/#get-requires-for-build-wheel get-requires-for-build-wheel] for details<br />
<br />
* distro packager may add any other required build dependency but must follow "necessary and sufficient" rule<br />
<br />
* presence of <tt><span style="color:green">%pyproject_build</span></tt> or <tt><span style="color:green">%pyproject_install</span></tt> in RPM specfile automatically adds build dependency on <tt><span style="color:green">pyproject-installer</span></tt>. But if that distribution is used for something different from aforementioned macros the corresponding requirement should be set explicitly<br />
<br />
* presence of <tt><span style="color:green">%tox_check</span></tt> or <tt><span style="color:green">%tox_check_pyproject</span></tt> in RPM specfile automatically adds build dependency on <tt><span style="color:green">tox</span></tt> and its required plugins. But if that distribution is used for something different from aforementioned macros the corresponding requirement should be set explicitly<br />
<br />
* dependencies required for <tt><span style="color:green">check</span></tt> or build docs must be RPM-conditional i.e., they can be opted out by RPM means<br />
<br />
* sources of upstream's dependencies can be managed with the help of <tt><span style="color:green">%pyproject_deps</span></tt> RPM macros. See https://www.altlinux.org/Management_of_Python_dependencies_sources for details.<br />
<br />
====Build with RPM====<br />
<tt><span style="color:green">rpm-build-python3</span></tt> provides RPM macro <tt><span style="color:green">%pyproject_build</span></tt> as a CLI interface for build frontend (See [https://pypi.org/project/pyproject-installer/ pyproject-installer] for details).<br />
* build should be done with the help of this macro unless otherwise is absolutely necessary<br />
<br />
=====Implementation details=====<br />
* built wheel will be placed into <tt><span style="color:green">{source directory}/dist/</span></tt> directory<br />
<br />
<br />
===Install===<br />
A [https://peps.python.org/pep-0427/ wheel] is a regular zip archive having special name and suffix ".whl". Thus, an installer mostly just verifies content of a wheel, unpacks it and lays out unpacked files if necessary.<br />
<br />
====Install with RPM====<br />
<tt><span style="color:green">rpm-build-python3</span></tt> provides RPM macro <tt><span style="color:green">%pyproject_install</span></tt> as a CLI interface for installer (See [https://pypi.org/project/pyproject-installer/ pyproject-installer] for details).<br />
* installation should be done with the help of this macro unless otherwise is absolutely necessary<br />
<br />
=====Implementation details=====<br />
* only the latest wheel built with <tt><span style="color:green">%pyproject_build</span></tt> will be installed by <tt><span style="color:green">%pyproject_install</span></tt><br />
<br />
====Bytecompilation====<br />
[https://peps.python.org/pep-0427/#details PEP427] says that wheel installers should compile any installed .py to .pyc (see [https://docs.python.org/3/tutorial/modules.html#compiled-python-files compiled-python-files] and [https://peps.python.org/pep-3147/ pyc directories] for details). But <tt><span style="color:green">rpm-build-python3</span></tt> already does this by default with the help of '''python3.compileall.py''' script which compiles Python modules with the given optimization level (disabled, '''-O''' switch removes assert statements, the '''-OO''' switch removes both assert statements and __doc__ strings). <br />
<br />
<br />
===Check===<br />
Testing is vital in Python eco-system. Never skip or disable tests unless it's absolutely necessary.<br />
<br />
Due to security reasons the hasher in ALT's build-farm is network-isolated environment and thus, testing in such an env can be very tricky or is not possible at all. Though the most of unit tests require nothing for run and <tt><span style="color:green">check</span></tt> should be enabled by default. In contrast, integration tests usually require Internet's availability and thereby, should be skipped. Nowadays the vast majority of projects use <tt><span style="color:green">pytest</span></tt> or stdlib's <tt><span style="color:green">unittest</span></tt> as tests' runner and <tt><span style="color:green">tox</span></tt> to automate testing.<br />
<br />
==== Check with RPM ====<br />
It's often required to run project's tests during downstream packaging in the global isolated environment. For example, the user of such environment is unprivileged (can't install distributions into global sitepackages) and has no access to Internet (can't install distributions from package indexes). On the other hand built Python distributions should not be unintentionally installed into user sitepackages to avoid their interference with any further distributions being tested. Though some of tests can be run in current Python environment without any change (e.g. flat layout and pure Python package), some may require setting of PYTHONPATH environment variable (e.g. src layout and pure Python package). But things may be more complex in case of arch-dependent Python packages, .pth hooks or entry_points plugins where PYTHONPATH way can't help. This is one of the reasons why venv(stdlib) or virtualenv(third-party) exists. There is really nice tool tox for automation of testing process. But it's overkill to use it for the aforementioned task, for example:<br />
* by default tox download and install dependencies of test env and dependencies of package (though this can be overcome with options and external plugins)<br />
* tox has many runtime dependencies<br />
<br />
===== Check with pyproject_installer =====<br />
The recommended way to run tests is one of RPM macros based on <tt><span style="color:green">pyproject_installer</span></tt>'s command <tt><span style="color:green">run</span></tt>:<br />
* <tt><span style="color:green">%pyproject_run</span></tt> '''''(i.e. python3 -m pyproject_installer run)'''''</tt> allows execution of arbitrary command within non-isolated venv-based Python virtual environment:<br />
** create minimal virtual environment with the help of stdlib's [https://docs.python.org/3/library/venv.html venv] that: <br />
*** has no installed pip, setuptools<br />
*** has access to system and user site packages<br />
** generate console scripts of system and user site packages to access them within venv<br />
** install built distribution into venv without any dependencies<br />
** spawn command in subprocess within venv preserving current environment variables<br />
** set <tt><span style="color:green">NO_INTERNET</span></tt> environment variable that can be used by tests' runner for making tests requring Internet conditional<br />
* <tt><span style="color:green">%pyproject_run_unittest</span></tt> '''''(i.e. <tt>python3 -m pyproject_installer run -- python3 -m unittest</tt>)''''' and <tt><span style="color:green">%pyproject_run_pytest</span></tt> '''''(i.e. <tt>python3 -m pyproject_installer run -- python3 -m pytest</tt>)''''' are the most commonly used test commands (<tt><span style="color:green">unittest</span></tt> and <tt><span style="color:green">pytest</span></tt> respectively)<br />
<br />
===== Check with tox =====<br />
<tt><span style="color:green">rpm-build-python3</span></tt> provides several RPM macros as a CLI interface for <span style="color:green">tox</span>:<br />
* <tt><span style="color:green">%tox_check</span></tt>:<br />
** set required tox's and pip's env variables for running in network-isolated env<br />
** pass down <tt><span style="color:green">NO_INTERNET</span></tt> env variable to tox env. This variable can be used by tests' runner for making tests requring Internet conditional<br />
** run <span>tox</span> with system site distributions<br />
** relax all tox env's dependencies<br />
** generate console scripts for every system site distribution defining them<br />
* <tt><span style="color:green">%tox_check_pyproject</span></tt>:<br />
** same as <tt><span style="color:green">%tox_check</span></tt> but tox will use a wheel built by <tt><span style="color:green">%pyproject_build</span></tt><br />
* <tt><span style="color:green">%tox_create_default_config</span></tt>:<br />
** creates a default tox configuration (<tt><span style="color:olive">tox.ini</span></tt>) in the current working directory with the following content:<syntaxhighlight lang="ini"><br />
[testenv]<br />
commands =<br />
pytest {posargs:-vra}<br />
</syntaxhighlight>This maybe helpful if you want to run tests under tox and Pytest as tests runner but upstream doesn't provide such a config or you want to override it with your own.<br>Override note: today's tox searches its config in the following order: pyproject.toml, tox.ini, setup.cfg ([https://tox.wiki/en/latest/config.html#configuration-discovery tox-configuration-discovery]).<br />
<br />
===Packaging===<br />
<br />
====Subpackages====<br />
* if docs or tests are required by something or somebody else they must be subpackaged into their own RPM packages, otherwise they must not be shipped.<br />
<br />
====Metadata====<br />
If a project is assumed to be reusable it must publish corresponding meta information. The generation of such data is a job of build backend.<br />
But there are projects which are intended only for internal usage and they don't want to produce any meta information in this case (usually such projects are not published on index like pypi.org).<br />
<br />
* installed metadata (content of dist-info directory) shouldn't be stripped any more than it's already done. Nowadays, only '''METADATA''' and '''entry_points.txt''' are actually used by metadata parsers (See [https://docs.python.org/3/library/importlib.metadata.html importlib.metadata] for details). This data is crucial for many aspects of Python eco-system.<br />
<br />
* <tt><span style="color:green">%pyproject_distinfo</span></tt> RPM macro can help if more finer-grained control over a packaged metadata is desired or required. This macro normalizes a given name according to PEP427 rules. Note: not everyone build backend follows these rules and can produce wheel having filename with '''.''' (dot character) and/or upper case characters in distribution name's part of that filename. See https://discuss.python.org/t/amending-pep-427-and-pep-625-on-package-normalization-rules/17226 for details. it's not always possible to predict produced wheel filename.<br />
<br />
==Migration to PEP517 in RPM specfile==<br />
More and more Python projects are migrating from legacy '''setup.py'''-packaging and completely removing this file from their tree. This makes it impossible to package such projects with old Python RPM macros<br />
which unconditionally rely on existent '''setup.py'''.<br />
<br />
===New RPM macros===<br />
In most of the cases the legacy RPM macros for build or install Python project can be (and must be) replaced with the modern ones e.g.:<br />
{| class="wikitable" style="text-align:center;"<br />
! legacy macro !! modern macro<br />
|-<br />
|python3_build<br />
|pyproject_build<br />
|-<br />
|python3_build_debug<br />
|pyproject_build<br />
|-<br />
|python3_install<br />
|pyproject_install<br />
|-<br />
|python3_build_install<br />
|pyproject_build and pyproject_install<br />
|}<br />
<br />
===New build dependencies===<br />
<br />
As it was said before a distro packager is responsible for specifying build requirements in RPM specfile.<br />
<br />
<br />
This can be done manually or [[Management_of_Python_dependencies_sources|automatically]].<br />
Current section describes only '''manual''' way to achieve it.<br />
<br />
<br />
All the static requirements for building a project are given in '''pyproject.toml'''.<br />
<br />
For example,<br />
<syntaxhighlight lang="TOML"><br />
[build-system]<br />
requires = ["setuptools"]<br />
build-backend = "setuptools.build_meta"<br />
</syntaxhighlight><br />
<br />
'''setuptools''' in turn requires '''wheel''' distribution to build a wheel.<br />
Thereby, the following build dependencies must be specified in RPM specfile explicitly:<br />
<syntaxhighlight lang="RPMSpec"><br />
BuildRequires: python3-module-setuptools<br />
BuildRequires: python3-module-wheel<br />
</syntaxhighlight><br />
<br />
{{Note| Building sdist or wheel may require additional distributions, names of which can only be obtained from a build backend.}}<br />
<br />
===Legacy setup.py-formatted projects===<br />
Even if a project still uses legacy packaging format it's possible to build such a project with PEP517/518-aware RPM macros.<br />
<br />
The following default configuration<br />
<syntaxhighlight lang="TOML"><br />
[build-system]<br />
requires = ["setuptools", "wheel"]<br />
build-backend = "setuptools.build_meta:__legacy__"<br />
</syntaxhighlight><br />
will be used if:<br />
* pyproject.toml file is missing<br />
* 'build-system' table is missing<br />
<br />
<br />
Additionally, the legacy <tt><span style="color:green">setuptools.build_meta:__legacy__</span></tt> backend will be used if:<br />
* 'build-backend' key of 'build-system' table is missing<br />
<br />
<br />
{{Note|<br />
Those default build dependencies must be specified in RPM specfile explicitly:<syntaxhighlight lang="RPMSpec"><br />
BuildRequires: python3-module-setuptools<br />
BuildRequires: python3-module-wheel<br />
</syntaxhighlight><br />
|warn}}<br />
<br />
===Installed metadata===<br />
The new format of metadata (<span>[https://packaging.python.org/en/latest/specifications/recording-installed-packages/#the-dist-info-directory/ dist-info] will be generated and packaged on migrating to PEP517-aware RPM macros.<br><br />
For example, <tt><span style="color:green">egg-info</span></tt> (previous format) vs <tt><span style="color:green">dist-info</span></tt>:<br />
<syntaxhighlight lang="diff"><br />
- my_distribution-1.0-py3.10.egg-info<br />
- my_distribution-1.0-py3.10.egg-info/dependency_links.txt<br />
- my_distribution-1.0-py3.10.egg-info/entry_points.txt<br />
- my_distribution-1.0-py3.10.egg-info/not-zip-safe<br />
- my_distribution-1.0-py3.10.egg-info/PKG-INFO<br />
- my_distribution-1.0-py3.10.egg-info/requires.txt<br />
- my_distribution-1.0-py3.10.egg-info/SOURCES.txt<br />
- my_distribution-1.0-py3.10.egg-info/top_level.txt<br />
+ my_distribution-1.0.dist-info<br />
+ my_distribution-1.0.dist-info/entry_points.txt<br />
+ my_distribution-1.0.dist-info/METADATA<br />
</syntaxhighlight><br />
<br />
===setuptools===<br />
'''setuptools''' is the mandatory dependency of legacy RPM macros, but it's an optional build backend for the new ones. Thus, '''setuptools''' is no longer pulled into a build environment just on usage of modern macros and should be specified explicitly if it's still needed.<br />
<br />
==Related==<br />
*[https://peps.python.org/pep-0517/ pep-0517]<br />
*[https://peps.python.org/pep-0518/ pep-0518]<br />
*[https://git.altlinux.org/people/slev/public/?p=python_spec.git;a=tree;h=refs/heads/main;hb=main Example of RPM specfile]<br />
*[https://packaging.python.org/en/latest/ Official packaging guide]<br />
*[https://docs.python.org/3/library/venv.html venv]<br />
[[Категория:Packaging]][[Категория:Python]]</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=NobodySubjectPolicy&diff=76533NobodySubjectPolicy2023-11-21T23:52:00Z<p>ArsenyMaslennikov: Новая страница: «{{DraftPolicy |responsible=arseny@ |discussion_link=https://lore.altlinux.org/devel/ZVTBCLVCmMnpMpJ6@cello/t/#u |discussion_since=2023-11-15 }} == Введение == Как известно, в файле {{term|passwd}} по умолчанию в наших системах присутствуют пользователь и группа {{term|nobody}}. Одно время в кругу разработчиков и администраторов хо...»</p>
<hr />
<div>{{DraftPolicy<br />
|responsible=arseny@<br />
|discussion_link=https://lore.altlinux.org/devel/ZVTBCLVCmMnpMpJ6@cello/t/#u<br />
|discussion_since=2023-11-15<br />
}}<br />
<br />
== Введение ==<br />
Как известно, в файле {{term|passwd}} по умолчанию в наших системах присутствуют пользователь и группа {{term|nobody}}.<br />
<br />
Одно время в кругу разработчиков и администраторов ходила мода считать этого пользователя "наименее привилегированным", будто ему почти ничего нельзя: в ФС почти нет файлов, ему доступных, у него нет логин-шелла, под ним нельзя запустить десктоп штатными средствами, и т. д.<br />
Из этого выводили ошибочное следствие, что какой-нибудь нетребовательный процесс-службу можно запускать прямо под {{term|nobody}}, чтобы отсечь ему доступ к "более важным" службам.<br />
Как только таких сервисов становится больше одного, оказывается, что все они работают с общими привилегиями, могут слать друг другу сигналы и т. д., то есть недостаточно изолированы друг от друга.<br />
Им просто следует работать под собственными системными UID, а концепция "наименее привилегированного uid" не имеет смысла.<br />
<br />
В [[Kernel|ядре Linux]] достаточно давно есть [https://docs.kernel.org/admin-guide/sysctl/fs.html#overflowgid-overflowuid понятие] {{term|overflowuid}}/{{term|overflowgid}}:<br />
зарезервированное значение uid и gid, которое используется, чтобы обозначить в одной подсистеме непредставимые значения uid и gid в файлах из другой подсистемы.<br />
Например, в файловых системах с 16-разрядными полями uid и gid вместо невлезающего значения будет записан {{term|overflowuid}}/{{term|overflowgid}}.<br />
Другой пример: NFS-клиент может представлять рута на клиентской машине {{term|overflowuid}}ом на сервере.<br />
Ныне разнородные апстримы сходятся на том, чтобы зафиксировать в качестве этого значения число <tt>((uint16_t)-2)</tt>, оно же <tt>65534</tt>, дефолт в ядре, и обозвать этого пользователя {{term|nobody}}. Тем самым они ''объединяют'' понятия {{term|nobody}} и {{term|overflow[ug]id}}.<br />
<br />
Вообще говоря, под пользователем {{term|nobody}} и группой {{term|nobody}} в системе не должно работать ничего, а в ФС на несъёмных устройствах хранения не должно создаваться файловых объектов с такими uid и gid.<br />
Для того, чтобы это гарантировать, следует ввести автоматические проверки хотя бы на этапе сборки пакетов.<ref>А лучше даже во время работы системы (что-то вроде seccomp-фильтра на всех процессах, запрещающего setuid и setgid в этого пользователя), но это более сложная задача, решения которой на ванильном ядре могут оказаться сверхнеэффективными.</ref><br />
<br />
== Нормативные предписания ==<br />
<small>Здесь и далее словосочетание "под {{term|nobody}}" сохраняет свой общепринятый смысл, но относится и к uid, и к основному gid.</small><br />
* В пакеты '''запрещается''' помещать файловые объекты под {{term|nobody}}. Исполнение правила контролирует sisyphus-check;<br />
* Мейнтейнеры не должны допускать, чтобы собираемые ими системные службы исполняли код под {{term|nobody}} или имели {{term|nobody}} в числе дополнительных (''supplementary'') групп. В будущем, возможно, будут применяться автоматические средства проверки выполнения этого правила;<br />
* Администраторам систем на базе Альт рекомендуется не запускать процессы под пользователем и группой {{term|nobody}} или помещать {{term|nobody}} в число дополнительных (''supplementary'') групп.<br />
<br />
== Примечания ==</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=Policy_Policy&diff=76251Policy Policy2023-11-14T20:29:47Z<p>ArsenyMaslennikov: </p>
<hr />
<div>{{Policy|since=14 марта 2008|responsible=[https://ru.wikipedia.org/wiki/%D0%9B%D0%B8%D0%BA%D1%83%D1%80%D0%B3_%D0%A1%D0%BF%D0%B0%D1%80%D1%82%D0%B0%D0%BD%D1%81%D0%BA%D0%B8%D0%B9 куда-то смылся]}}<br />
{{span|font-size: 180%|Полиси принятия/изменения полиси}}<br />
<br />
Без правил принятия policy таковые будут с трудом пробиваться наружу. Установление временны́х рамок обсуждения полиси поддерживает в тонусе мейнтейнеров, которым нужно вовремя реагировать на те полиси, которые их не устраивают, а также задаёт видимые границы обсуждения для того, чтобы предлагающий policy мог спланировать как обсуждение, так и реализацию.<br />
<br />
В тексте ниже новое policy означает также и поправку к существующему, а также отмену устаревшего policy.<br />
<br />
== Легковесный процесс принятия policy aka «мы ещё не дебиан» ==<br />
<br />
=== Участвующие лица ===<br />
* Автор, выдвигающий предложение (член Team).<br />
* Арбитр.<br />
* Члены Team.<br />
<br />
=== Обсуждение черновика ===<br />
* Автор создаёт черновик policy на wiki с пометкой шаблоном [[:Template:DraftPolicy|«Черновик политики»]].<br />
* Автор публикует предложение обсудить новый черновик в списке рассылки {{lists|devel}} и добавляет в черновик ссылку на обсуждение (в поле шаблона).<br />
* Если за две недели не находится существенных технических возражений к опубликованному черновику (мера существенности возражений определяется арбитром), то черновик считается принятым.<br />
* В случае нахождения существенных технических возражений черновик считается отвергнутым.<br />
<br />
=== Принятие черновика ===<br />
* Арбитр меняет шаблон [[:Template:DraftPolicy|«Черновик политики»]] на шаблон [[:Template:Policy|«Действующая политика»]].<br />
* Принятое policy обязательно к исполнению в новых пакетах<br />
* Приведение существующих пакетов к виду, совместимому с новым policy, является обязанностью автора (естественно, автор не обязан в одиночку править все пакеты, а может агитировать на это мейнтейнеров и других членов Team).<br />
* Долгое время не приложенный мейнтейнером патч для приведения к совместимости с новым policy является основанием для NMU.<br />
* Дальнейшее поддержание пакетов в виде, совместимом с новым policy, является обязанностью мейнтейнеров.<br />
<br />
=== Отвергнутые черновики ===<br />
* Арбитр убирает пометку об обсуждении из черновика.<br />
* Автор может в любой момент переработать отвергнутый черновик и вновь предложить его для обсуждения.<br />
<br />
=== Арбитр ===<br />
Арбитр выбирается методом ментального хмыканья среди наиболее блестящих и выдающихся своей беспристрастностью team-овцев.<br />
<br />
В случае, когда предлагаемый черновик непосредственно затрагивает текущего арбитра или арбитр не обладает достаточным пониманием разбираемого вопроса, он может на своё усмотрение делегировать свои обязанности другому члену team.<br />
<br />
Арбитры:<br />
* с 14 марта 2008 — настоящее время: Дмитрий Левин aka {{man|ldv}}.</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=%D0%A0%D0%B5%D1%88%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BF%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC_PulseAudio_%D0%B8_PipeWire&diff=75883Решение проблем PulseAudio и PipeWire2023-11-02T12:20:12Z<p>ArsenyMaslennikov: Alas, the spelling is "alsamixer"</p>
<hr />
<div>{{stub}}<br />
{{Внимание|Статья еще не окончена!}}<br />
=PulseAudio=<br />
=PipeWire=<br />
{{Note|Для работы с утилитами Pipewire необходимо установить пакет {{pkg|pipewire-utils}}}}<br />
==PipeWire не видит микрофон==<br />
Попробуйте выключить в конфигурационном файле параметр '''api.alsa.use-acp''' и/или '''api.alsa.use-ucm'''.<br />
===Если используется '''pipewire-media-session'''===<br />
{{note|для проверки, установлен ли Pipewire, скомандуйте: {{cmd|$ rpm -q pipewire}} }}<br />
Приведите текстовым редактором от рута в файле {{path|/usr/share/pipewire/media-session.d/alsa-monitor.conf}} выделенные параметры к указанным значениям:<br />
...<br />
rules = [<br />
{<br />
...<br />
actions = {<br />
update-props = {<br />
...<br />
'''api.alsa.use-acp = false'''<br />
...<br />
Для проверки доступных устройств ввода скомандуйте: {{cmd|$ pw-link -iol | grep input}}<br />
===Если используется '''wireplumber'''===<br />
{{note|для проверки, установлен ли Wireplumber, скомандуте {{cmd|$ rpm -q wireplumber}} }}<br />
Приведите текстовым редактором от рута в файле {{path|/usr/share/wireplumber/main.lua.d/50-alsa-config.lua}} выделенные параметры к указанным значениям:<br />
...<br />
alsa_monitor.rules = {<br />
{<br />
...<br />
apply_properties = {<br />
-- Использование устройств ALSA-Card-Profile. Они используют UCM или<br />
-- конфигурацию профиля для настройки параметров устройства и микшера.<br />
-- '''["api.alsa.use-acp"] = true''',<br />
<br />
-- Использование UCM вместо profile по возможности. Можно отключить,<br />
-- чтобы не пытаться использовать профиль UCM.<br />
'''["api.alsa.use-ucm"] = true''',<br />
...<br />
Перезапустите PipeWire: {{cmd|$ systemctl --user enable --now pipewire-media-session}}<br />
<br />
И проверьте список доступных устройств: {{cmd|$ wpctl status}}<br />
{{Note|для установки pactl и wpctl скомандуйте {{cmd|# apt-get install /usr/bin/{pa,wp}ctl}} }}<br />
==При подключении нового устройства звук на него автоматически не переключается==<br />
Чтобы автоматически переключаться на вновь подключенные устройства, добавьте в {{path|~/.config/pipewire/pipewire.conf}} или раскомментируйте в {{path|/usr/share/pipewire/pipewire-pulse.conf}} следующую строку (выделена жирным):<br />
...<br />
context.exec = [<br />
{ path = "pactl" args = "load-module module-always-sink" }<br />
'''{ path = "pactl" args = "load-module module-switch-on-connect" }'''<br />
# { path = "/usr/bin/sh" args = "~/.config/pipewire/default.pw" }<br />
]<br />
...<br />
Для применения изменений перезапустите пользовательские службы: {{cmd|$ systemctl --user restart pipewire{,-pulse} }}<br />
===Звук на наушники Bluetooth автоматически не переключается===<br />
Скомандуйте {{cmd|$ pactl load-module module-switch-on-connect}} и настройте среду рабочего стола на автоматический запуск этой команды при входе в систему.<br />
<br />
Возможно, ещё потребуется выполнить: {{cmd|$ wpctl set-default <id>}}. Найти <id> можно следующим способом:<br />
{|class="wikitable mw-collapsible mw-collapsed" style="float:center; margin-left:2em" <br />
!$ wpctl status&nbsp;<br />
|-<br />
|<pre><br />
PipeWire 'pipewire-0' [0.3.71, petr@atk, cookie:1976916996]<br />
└─ Clients:<br />
32. pipewire-media-session [0.3.71, petr@atk, pid:10780]<br />
33. pipewire-media-session [0.3.71, petr@atk, pid:10780]<br />
39. pipewire [0.3.71, petr@atk, pid:10781]<br />
49. wpctl [0.3.71, petr@atk, pid:11459]<br />
50. pipewire [0.3.71, petr@atk, pid:10781]<br />
<br />
Audio<br />
├─ Devices:<br />
│ 41. Built-in Audio [alsa]<br />
│ <br />
├─ Sinks:<br />
│ * 42. Built-in Audio Analog Stereo [vol: 0.74] <-- Здесь <id> = 42<br />
│ <br />
├─ Sink endpoints:<br />
│ <br />
├─ Sources:<br />
│ * 43. Built-in Audio Analog Stereo [vol: 0.74] <-- Здесь <id> = 43<br />
│ <br />
├─ Source endpoints:<br />
│ <br />
└─ Streams:<br />
<br />
Video<br />
├─ Devices:<br />
│ <br />
├─ Sinks:<br />
│ <br />
├─ Sink endpoints:<br />
│ <br />
├─ Sources:<br />
│ <br />
├─ Source endpoints:<br />
│ <br />
└─ Streams:<br />
<br />
Settings<br />
└─ Default Configured Node Names:<br />
0. Audio/Sink alsa_output.pci-0000_00_05.0.analog-stereo<br />
</pre><br />
|}<br />
===Нет звука после подключения устройства Bluetooth===<br />
По состоянию на 2020-12-07, если после подключения устройства Bluetooth нет звука, скорее всего потребуется переключить стандартный аудиопоток или перенаправить его к требуемому.<br />
<br />
Для просмотра доступных потоков скомандуйте:<br />
{|class="wikitable mw-collapsible mw-collapsed" style="float:center; margin-left:2em" <br />
!$ pactl list sinks&nbsp;<br />
|-<br />
|<br />
<pre><br />
Аудиоприёмник №42<br />
Состояние: SUSPENDED<br />
Имя: alsa_output.pci-0000_00_05.0.analog-stereo<br />
Описание: Built-in Audio Analog Stereo<br />
Драйвер: PipeWire<br />
Спецификация отсчётов: s16le 2-канальный 4800<br />
Схема каналов: front-left,front-right<br />
Модуль-владелец: 4294967295<br />
Звук выключен: нет<br />
Громкость: front-left: 48287 / 74% / -7,96 dB, front-right: 48287 / 74% / -7,96 dB<br />
баланс 0,00<br />
Базовая громкость: 65536 / 100% / 0,00 dB<br />
Мониторный источник: alsa_output.pci-0000_00_05.0.analog-stereo.monitor<br />
Задержка: 0 мкс, настроено на 0 мкс<br />
Флаги: HARDWARE HW_MUTE_CTRL HW_VOLUME_CTRL DECIBEL_VOLUME LATENCY <br />
Свойства:<br />
object.path = "alsa:pcm:0:front:0:playback"<br />
api.alsa.path = "front:0"<br />
api.alsa.pcm.card = "0"<br />
api.alsa.pcm.stream = "playback"<br />
audio.channels = "2"<br />
audio.position = "FL,FR"<br />
device.routes = "2"<br />
alsa.resolution_bits = "16"<br />
device.api = "alsa"<br />
device.class = "sound"<br />
alsa.class = "generic"<br />
alsa.subclass = "generic-mix"<br />
alsa.name = "Intel 82801AA-ICH"<br />
alsa.id = "Intel ICH"<br />
alsa.subdevice = "0"<br />
alsa.subdevice_name = "subdevice #0"<br />
alsa.device = "0"<br />
alsa.card = "0"<br />
alsa.card_name = "Intel 82801AA-ICH"<br />
alsa.long_card_name = "Intel 82801AA-ICH with AD1980 at irq 21"<br />
alsa.driver_name = "snd_intel8x0"<br />
device.profile.name = "analog-stereo"<br />
device.profile.description = "Analog Stereo"<br />
card.profile.device = "4"<br />
device.id = "41"<br />
factory.name = "api.alsa.pcm.sink"<br />
priority.driver = "1009"<br />
priority.session = "1009"<br />
media.class = "Audio/Sink"<br />
node.nick = "Intel 82801AA-ICH"<br />
node.name = "alsa_output.pci-0000_00_05.0.analog-stereo"<br />
device.description = "Built-in Audio"<br />
device.icon_name = "audio-card-analog"<br />
device.bus = "pci"<br />
device.bus_path = "pci-0000:00:05.0"<br />
device.form_factor = "internal"<br />
node.pause-on-idle = "false"<br />
factory.id = "18"<br />
clock.quantum-limit = "8192"<br />
client.id = "33"<br />
node.driver = "true"<br />
factory.mode = "merge"<br />
audio.adapt.follower = ""<br />
library.name = "audioconvert/libspa-audioconvert"<br />
object.id = "42"<br />
object.serial = "42"<br />
device.enum.api = "udev"<br />
api.alsa.card = "0"<br />
api.alsa.card.name = "Intel 82801AA-ICH"<br />
api.alsa.card.longname = "Intel 82801AA-ICH with AD1980 at irq 21"<br />
device.plugged.usec = "5422646"<br />
sysfs.path = "/devices/pci0000:00/0000:00:05.0/sound/card0"<br />
device.subsystem = "sound"<br />
device.vendor.id = "0x8086"<br />
device.vendor.name = "Intel Corporation"<br />
device.product.id = "0x2415"<br />
device.product.name = "82801AA AC'97 Audio Controller"<br />
device.name = "alsa_card.pci-0000_00_05.0"<br />
device.nick = "Intel 82801AA-ICH"<br />
api.alsa.use-acp = "true"<br />
api.acp.auto-profile = "false"<br />
api.acp.auto-port = "false"<br />
api.dbus.ReserveDevice1 = "Audio0"<br />
device.string = "0"<br />
Порты:<br />
analog-output;output-amplifier-on: Analog Output / Amplifier (тип: Аналоговый, приоритет: 9910, доступность неясна)<br />
analog-output;output-amplifier-off: Analog Output / No Amplifier (тип: Аналоговый, приоритет: 9900, доступность неясна)<br />
Активный порт: analog-output;output-amplifier-on<br />
Форматы:<br />
pcm<br />
</pre><br />
|}<br />
и {{cmd|$ pactl set-default-sink}} для смены стандартного потока на bluetooth устройство.<br />
<br />
Пример использования: {{cmd|$ pactl set-default-sink 42}}<br />
<br />
Можно автоматизировать через udev, используя [https://gist.github.com/tinywrkb/04e7fd644afa9b92d33a3a99ab07ee9e данный скрипт] как пример.<br />
{{Note|Хотя на Github указано, что он уже не нужен после v0.3.21 или GIT. В P10 на 22.09.23 - 0.3.71}}<br />
Обсуждение данной проблемы можно посмотреть [https://www.reddit.com/r/archlinux/comments/jydd02/pipewirepulse_03164_in_testing_now_replaces/gd3m7fu/?context=3 здесь]. По словам автора скрипта, профиль гарнитуры (HSP) все еще может иметь проблемы.<br />
==Низкая громкость==<br />
После [[С PulseAudio на PipeWire|замены PulseAudio на Pipewire]] громкость звука может оставаться прежней, но после перезагрузки становится существенно ниже. Для исправления данной проблемы откройте:<br />
*в консоли — {{cmd|alsamixer}},<br />
*:по {{button|F6}} выберите стрелками нужную звуковую карту и нажмите {{button|Enter}}),<br />
*:клавишами {{button|↑}} / {{button|↓}} выставьте громкость ALSA в колонке '''Master''' в 100%,<br />
*:для выхода нажмите {{button|Esc}},<br />
*:для сохранения параметров ALSA после перезагрузки выполните {{cmd|alsactl}};<br />
*в KDE — настройку звуковых устройств из системного лотка,<br />
*:дальше — мышкой.<br />
==Изменение частоты дискретизации==<br />
По умолчанию PipeWire устанавливает фиксированную глобальную частоту дискретизации в 48 кГц. Если требуется иное (например, у вас есть ЦАП, поддерживающий более высокое значение), можно изменить умолчальное значение в системном ({{path|/usr/share/}}) или в пользовательском ({{path|~/.config/}}) файле {{path|pipewire/pipewire.conf}}, раскомментировав строчку '''default.clock.rate''' и заменив '''48000''' на свое значение:<br />
...<br />
context.properties = {<br />
...<br />
## Properties for the DSP configuration.<br />
'''#default.clock.rate = 48000'''<br />
...<br />
==Изменение разрешённых частот дискретизации==<br />
PipeWire также может динамически изменять поддерживаемую вашим ЦАП выходную частоту дискретизации, соответствующую таковой у воспроизводимого аудиопотока. <br />
<br />
Требуемые значения задаются в системном ({{path|/usr/share/}}) или в пользовательском ({{path|~/.config/}}) файле {{path|pipewire/pipewire.conf}}:<br />
...<br />
context.properties = { <br />
...<br />
'''default.clock.allowed-rates = [ частота_1 частота_2 частота_3 ... ]'''<br />
...<br />
Например, {{cmd|[ 44100 48000 88200 96000 ]}}. Поддерживаемые значения должны быть описаны в инструкции к вашему ЦАП.<br />
<br />
По [https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1523 словам разработчиков], PipeWire допускает до 16 различных частот дискретизации и переключается по возможности. Это означает, что с приведёнными выше настройками передискретизация не производится, если используемая в аудиопотоке частота поддерживается устройством.<br />
<br />
==Нет звука или <code>pactl info</code> выдаёт «Ошибка подключения: Соединение отвергнуто»==<br />
Данная ошибка говорит о том, что приложение не может присоединиться к службе PipeWire-Pulse. <br />
<br />
Убедитесь, что файл {{path|/usr/share/pipewire/pipewire-pulse.conf}} существует и не пуст, и перезапустите пользовательскую службу:<br />
<br />
{{cmd|$ systemctl restart --user pipewire-pulse}}<br />
<br />
Если файла нет, попробуйте переустановить пакет pipewire и перезагрузиться (перезапуск pipewire и pipewire-pulse помог мне лишь частично):<br />
<br />
{{cmd|# apt-get install --reinstall pipewire}}<br />
==Заметная задержка звука при воспроизведении==<br />
Обычно данная проблема возникает после отключения узла в период неактивности.<br />
===При использовании ''pipewire-media-session''===<br />
Отключить задержку можно путём редактирования одного из файлов {{path|/usr/share/pipewire/media-session.d/*-monitor.conf}} в зависимости от того, где происходит задержка.<br />
<br />
Например: {{cmd|# mcedit /usr/share/pipewire/media-session.d/alsa-monitor.conf}}<br />
<br />
Для отключения нужно заменить значение {{cmd|session.suspend-timeout-seconds}} на 0 или поэкспериментировать с другими значениями.<br />
<br />
Либо закомментируйте в файле {{path|/usr/share/pipewire/media-session.d/media-session.conf}} строку '''suspend-node'''.<br />
<br />
Для применения перезагрузитесь или перезапустите потльзовательские службы: {{cmd|$ systemctl restart --user pipewire{,-pulse} }}<br />
===При использовании ''wireplumber''===<br />
Для переопределения умолчальных настроек создайте системный ({{path|/usr/share/}}) или пользовательский ({{path|~/.config/}}) файл {{path|wireplumber/main.lua.d/51-disable-suspension.lua}} со следующим содержимым:<br />
table.insert (alsa_monitor.rules, {<br />
matches = {<br />
{<br />
-- Соответствует всем источникам.<br />
{ "node.name", "matches", "alsa_input.*" },<br />
},<br />
{<br />
-- Соответствует всем выводам.<br />
{ "node.name", "matches", "alsa_output.*" },<br />
},<br />
},<br />
apply_properties = {<br />
["session.suspend-timeout-seconds"] = 0, -- 0 выключает приостановку<br />
},<br />
})<br />
Вместо полного отключения можно задать желаемое число секунд задержки перед приостановкой.<br />
==Пропадание звука при проигрывании других потоков==<br />
В журнале пользовательской службы {{cmd|$ journalctl --user -u pipewire-pulse}} могут обнаружиться такие строки:<br />
pipewire-pulse[21740]: pulse-server 0x56009b9d5de0: [Nightly] UNDERFLOW channel:0 offset:370676 underrun:940<br />
===При использовании ''pipewire-media-session''===<br />
Согласно [https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Troubleshooting#underrununderflow-and-broken-pipe-errors официальному гайду PipeWire], для решения данной проблемы нужно раскомментировать/изменить значение параметра '''api.alsa.headroom = 1024''' в системном ({{path|/usr/share/}}) или в пользовательском ({{path|~/.config/}}) файле<br />
<br />
{{path|pipewire/media-session.d/alsa-monitor.conf}}.<br />
===При использовании ''wireplumber''===<br />
Внести этот параметр в системный ({{path|/usr/share/}}) или в пользовательский ({{path|~/.config/}}) файл<br />
<br />
{{path|wireplumber/main.lua.d/50-alsa-config.lua}}:<br />
apply_properties = {<br />
["api.alsa.headroom"] = 1024,<br />
},<br />
==Искажённый звук==<br />
*Найдите проблемную lля микрофонов звуковую карту в alsamixer и уменьшите уровень "Mic Boost" или "Internal Mic Boost".<br />
*Попробуйте уменьшить частоту дискретизации до 44100 (44.1 кГц), как описано в разделе [[#Изменение частоты дискретизации по умолчанию]].<br />
==Различные проблемы после простоя==<br />
Если после пробуждения системы звук пропал или исказился, может потребоваться переинициализация ALSA: {{cmd|# alsactl init}}<br />
==Источники==<br />
*[https://wiki.archlinux.org/title/PulseAudio_(Русский)/Troubleshooting_(Русский) Arch - PulseAudio, Решение проблем]<br />
*[https://wiki.archlinux.org/title/PipeWire_(Русский)#Решение_проблем Arch - PipeWire, Решение проблем]<br />
*[https://wiki.archlinux.org/title/PipeWire#Troubleshooting Arch - PipeWire, Troubleshooting]</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=Usrmerge/FurtherOptions&diff=75425Usrmerge/FurtherOptions2023-10-24T14:05:34Z<p>ArsenyMaslennikov: </p>
<hr />
<div>Заранее приношу извинения, набирал текст второпях; надеюсь, не допустил фактических ошибок. -- arseny@<br />
<br />
=== Статус ===<br />
Сейчас у нас в пакете usrmerge есть скрипт, способный аккуратно перенести файлы и каталоги из unmerged-legacy-каталогов под /usr. Возможно, в нём потребуется переработать обработку уже существующих симлинков не вида <tt>/$x/$y <-> /usr/$x/$y</tt>. Симлинки указанного вида он восстанавливать умеет; в коде они обнаруживаются, и для них запрограммировано явное действие.<br />
<br />
=== Требует дискуссии ===<br />
В процессе подготовки базовой сборочной среды, в которой {{path|/bin}}, {{path|/sbin}} и {{path|/lib*}} являются симлинками внутрь {{path|/usr}}, обнаружилось, что:<br />
* пакеты имеют зависимости на файлы в этих каталогах, например, <tt>Requires: /bin/awk</tt>;<br />
* пути в {{path|/bin}} и проч. прописываются в hashbang генерируемых скриптов, и это не только <tt>/bin/sh</tt>;<br />
...<br />
Стало понятно, что для ручного исправления всего этого хозяйства потребуется очень много усилий, и нужно в макс. возможной степени автоматизировать переход.<br />
<br />
Пакеты можно разбить на категории сложности:<br />
# Те, что ничего не кладут в {{path|/}} и не требуют изменений.<br />
# Те, что помещают файлы или симлинки в {{path|/bin}}, {{path|/sbin}}. Сейчас это делается при помощи кода в спеках; было бы желательно автоматизировать такое размещение на обеих hier, что и предлагается обсудить.<br />
# Те, что помещают файлы в {{path|/lib/*}}. Они либо не требуют прямых изменений (потому что кладут файлы в каталог под макросом, например, <tt>%_tmpfilesdir</tt>, либо к каталогу, с которым они работают, нужно приписать <tt>/usr</tt>.<br />
<br />
Можно выделить два тактических направления движения вперёд:<br />
# Запатчить rpm, чтобы тот при установке/обновлении/удалении пакетов определял, будет ли установлен, обновлён или удалён файл вида <tt>/usr/$d/$x</tt>, и в этом случае проводил аналогичное действие с <tt>/$d/$x</tt>, если это необходимо (автор идеи: <tt>legion@</tt>)<br />
# Попытаться соорудить вспомогательную логику на макросах, и включить её в состав {{pkg|rpm-build}}. В репозиториях без поддержки unmerged-usr эти макросы будут раскрываться в то, что нужно включить в <tt>%install</tt>, <tt>%files</tt>, <tt>%post</tt> (автор идеи: <tt>iv@</tt>; я пока считаю, что мы не потянем ручные правки такого масштаба в спеках)<br />
<br />
==== Доводы в поддержку патчить RPM ====<br />
* Патч накладывается в одном месте и решает подзадачу целиком.<br />
** Соответственно, ему легко довольно быстро пройти через сборочницу.<br />
<br />
==== Доводы против патчить RPM ====<br />
* Ваня утверждает, что генерируемые симлинки не будут никому принадлежать в смысле rpmdb или даже apt, и это невозможно изменить.<br />
<br />
==== Доводы в поддержку патчить секции спеков ====<br />
* Не нужно вникать в то, как RPM устанавливает файлы.<br />
* Ваня счёл, что пакетов, где нужно будет это сделать, немного: лишь те, которые удовлетворяют зависимостям на unmerged-usr-пути, и из их <tt>%install</tt>-секции и так придётся убирать код, перекладывающий файлы в {{path|/bin}}, etc. Этим путём пошли SuSE, но у них можно глобально на уровне сборочницы переключать ряд макросов.<br />
** <tt>glebfm@</tt> заявил, что мы можем почти так же: нам ничто не мешает переключать макросы в пакете {{pkg|rpm-build}}, разве что таким изменениям тоже нужно будет быть собранными в виде заданий и пройти все проверки.<br />
<br />
==== Доводы против патчить секции спеков ====<br />
* Не все из участников обсуждения уверены, что <tt>%post</tt>-скрипты, создающие файл в {{path|/bin}}, смогут правильно создать <tt>/bin/sh</tt> при установке пакета, его содержащего (может быть, в этом случае просто нужна особая логика).<br />
* Около 400 пакетов потребуется не просто исправить, но и пропустить через сборочницу. Существенную их часть будет желательно собрать либо в одной транзакции, либо хотя бы между публикациями сизифа, чтобы пакеты могли устанавливаться в сборочную среду.</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=Team/Join/PossibleImprovements&diff=75287Team/Join/PossibleImprovements2023-10-20T14:37:19Z<p>ArsenyMaslennikov: </p>
<hr />
<div>=== Что можно улучшить в процедуре или инфраструктуре Team/Join? ===<br />
* Не хватает роботов-пингеров и вообще таймаутов по неактивности (7-8 месяцев (180 + 60 суток), или 13-14 месяцев (365 + 60 суток) в процедуре.<br />
** Может быть, тоже не хватает календареподобного обзорного интерфейса, аккумулирующего информацию из багзиллы.<br />
* Когда секретарь пишет в багрепорт ремарку вида <tt>T/J/S -> 1.3.</tt>, есть шанс, что не все читатели багрепорта осознают<ref>[https://bugzilla.altlinux.org/show_bug.cgi?id=41672#c20 bug 41672, T/J/S 3.5], ментор не знает, что его ход.</ref><ref>[https://bugzilla.altlinux.org/show_bug.cgi?id=46729#c4 bug 46729, T/J/S 1.3], ментор не догадывается, что ему нужно подтвердить готовность кандидата ''начинать собирать пакеты''.</ref>, что это означает и чьей реакции ждут участники процедуры. Может быть, робот должен добавлять короткий (1-2 предложения) справочный хинт на естественном языке в новый комментарий.</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=Team/Join/PossibleImprovements&diff=75286Team/Join/PossibleImprovements2023-10-20T14:36:20Z<p>ArsenyMaslennikov: Новая страница: «=== Что можно улучшить в процедуре или инфраструктуре Team/Join? === * Не хватает роботов-пингеров и вообще таймаутов по неактивности (7-8 месяцев (180 + 60 суток), или 13-14 месяцев (365 + 60 суток) в процедуре. ** Может быть, тоже не хватает календареподобного обзорного инт...»</p>
<hr />
<div>=== Что можно улучшить в процедуре или инфраструктуре Team/Join? ===<br />
* Не хватает роботов-пингеров и вообще таймаутов по неактивности (7-8 месяцев (180 + 60 суток), или 13-14 месяцев (365 + 60 суток) в процедуре.<br />
** Может быть, тоже не хватает календареподобного обзорного интерфейса, аккумулирующего информацию из багзиллы.<br />
* Когда секретарь пишет в багрепорт ремарку вида <tt>T/J/S -> 1.3.</tt>, есть шанс, что не все читатели багрепорта осознают<ref>[https://bugzilla.altlinux.org/show_bug.cgi?id=41672#c20 bug 41672, T/J/S 3.5], ментор не знает, что его ход.</ref><ref>[https://bugzilla.altlinux.org/show_bug.cgi?id=46729#c4 bug 46729, T/J/S 1.3], ментор не догадывается, что ему нужно подтвердить готовность кандидата.</ref>, что это означает и чьей реакции ждут участники процедуры. Может быть, робот должен добавлять короткий (1-2 предложения) справочный хинт на естественном языке в новый комментарий.</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=Usrmerge/FurtherOptions&diff=75275Usrmerge/FurtherOptions2023-10-19T12:31:04Z<p>ArsenyMaslennikov: /* Доводы против патчить секции спеков */</p>
<hr />
<div>Заранее приношу извинения, набирал текст второпях; надеюсь, не допустил фактических ошибок. -- arseny@<br />
<br />
=== Статус ===<br />
Сейчас у нас в пакете usrmerge есть скрипт, способный аккуратно перенести файлы и каталоги из unmerged-legacy-каталогов под /usr. Возможно, в нём потребуется переработать обработку уже существующих симлинков не вида <tt>/$x/$y <-> /usr/$x/$y</tt>. Симлинки указанного вида он восстанавливать умеет; в коде они обнаруживаются, и для них запрограммировано явное действие.<br />
<br />
=== Требует дискуссии ===<br />
В процессе подготовки базовой сборочной среды, в которой {{path|/bin}}, {{path|/sbin}} и {{path|/lib*}} являются симлинками внутрь {{path|/usr}}, обнаружилось, что:<br />
* пакеты имеют зависимости на файлы в этих каталогах, например, <tt>Requires: /bin/awk</tt>;<br />
* пути в {{path|/bin}} и проч. прописываются в hashbang генерируемых скриптов, и это не только <tt>/bin/sh</tt>;<br />
...<br />
Стало понятно, что для ручного исправления всего этого хозяйства потребуется очень много усилий, и нужно в макс. возможной степени автоматизировать переход.<br />
<br />
Пакеты можно разбить на категории сложности:<br />
# Те, что ничего не кладут в {{path|/}} и не требуют изменений.<br />
# Те, что помещают файлы или симлинки в {{path|/bin}}, {{path|/sbin}}. Сейчас это делается при помощи кода в спеках; было бы желательно автоматизировать такое размещение на обеих hier, что и предлагается обсудить.<br />
# Те, что помещают файлы в {{path|/lib/*}}. Они либо не требуют прямых изменений (потому что кладут файлы в каталог под макросом, например, `%_tmpfilesdir`, либо к каталогу, с которым они работают, нужно приписать <tt>/usr</tt>.<br />
<br />
Можно выделить два тактических направления движения вперёд:<br />
# Запатчить rpm, чтобы тот при установке/обновлении/удалении пакетов определял, будет ли установлен, обновлён или удалён файл вида <tt>/usr/$d/$x</tt>, и в этом случае проводил аналогичное действие с <tt>/$d/$x</tt>, если это необходимо (автор идеи: <tt>legion@</tt>)<br />
# Попытаться соорудить вспомогательную логику на макросах, и включить её в состав {{pkg|rpm-build}}. В репозиториях без поддержки unmerged-usr эти макросы будут раскрываться в то, что нужно включить в <tt>%install</tt>, <tt>%files</tt>, <tt>%post</tt> (автор идеи: <tt>iv@</tt>; я пока считаю, что мы не потянем ручные правки такого масштаба в спеках)<br />
<br />
==== Доводы в поддержку патчить RPM ====<br />
* Патч накладывается в одном месте и решает подзадачу целиком.<br />
** Соответственно, ему легко довольно быстро пройти через сборочницу.<br />
<br />
==== Доводы против патчить RPM ====<br />
* Ваня утверждает, что генерируемые симлинки не будут никому принадлежать в смысле rpmdb или даже apt, и это невозможно изменить.<br />
<br />
==== Доводы в поддержку патчить секции спеков ====<br />
* Не нужно вникать в то, как RPM устанавливает файлы.<br />
* Ваня счёл, что пакетов, где нужно будет это сделать, немного: лишь те, которые удовлетворяют зависимостям на unmerged-usr-пути, и из их <tt>%install</tt>-секции и так придётся убирать код, перекладывающий файлы в {{path|/bin}}, etc. Этим путём пошли SuSE, но у них можно глобально на уровне сборочницы переключать ряд макросов.<br />
** <tt>glebfm@</tt> заявил, что мы можем почти так же: нам ничто не мешает переключать макросы в пакете {{pkg|rpm-build}}, разве что таким изменениям тоже нужно будет быть собранными в виде заданий и пройти все проверки.<br />
<br />
==== Доводы против патчить секции спеков ====<br />
* Не все из участников обсуждения уверены, что <tt>%post</tt>-скрипты, создающие файл в {{path|/bin}}, смогут правильно создать <tt>/bin/sh</tt> при установке пакета, его содержащего (может быть, в этом случае просто нужна особая логика).<br />
* Около 400 пакетов потребуется не просто исправить, но и пропустить через сборочницу. Существенную их часть будет желательно собрать либо в одной транзакции, либо хотя бы между публикациями сизифа, чтобы пакеты могли устанавливаться в сборочную среду.</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=Usrmerge/FurtherOptions&diff=75274Usrmerge/FurtherOptions2023-10-19T12:30:19Z<p>ArsenyMaslennikov: /* Требует дискуссии */</p>
<hr />
<div>Заранее приношу извинения, набирал текст второпях; надеюсь, не допустил фактических ошибок. -- arseny@<br />
<br />
=== Статус ===<br />
Сейчас у нас в пакете usrmerge есть скрипт, способный аккуратно перенести файлы и каталоги из unmerged-legacy-каталогов под /usr. Возможно, в нём потребуется переработать обработку уже существующих симлинков не вида <tt>/$x/$y <-> /usr/$x/$y</tt>. Симлинки указанного вида он восстанавливать умеет; в коде они обнаруживаются, и для них запрограммировано явное действие.<br />
<br />
=== Требует дискуссии ===<br />
В процессе подготовки базовой сборочной среды, в которой {{path|/bin}}, {{path|/sbin}} и {{path|/lib*}} являются симлинками внутрь {{path|/usr}}, обнаружилось, что:<br />
* пакеты имеют зависимости на файлы в этих каталогах, например, <tt>Requires: /bin/awk</tt>;<br />
* пути в {{path|/bin}} и проч. прописываются в hashbang генерируемых скриптов, и это не только <tt>/bin/sh</tt>;<br />
...<br />
Стало понятно, что для ручного исправления всего этого хозяйства потребуется очень много усилий, и нужно в макс. возможной степени автоматизировать переход.<br />
<br />
Пакеты можно разбить на категории сложности:<br />
# Те, что ничего не кладут в {{path|/}} и не требуют изменений.<br />
# Те, что помещают файлы или симлинки в {{path|/bin}}, {{path|/sbin}}. Сейчас это делается при помощи кода в спеках; было бы желательно автоматизировать такое размещение на обеих hier, что и предлагается обсудить.<br />
# Те, что помещают файлы в {{path|/lib/*}}. Они либо не требуют прямых изменений (потому что кладут файлы в каталог под макросом, например, `%_tmpfilesdir`, либо к каталогу, с которым они работают, нужно приписать <tt>/usr</tt>.<br />
<br />
Можно выделить два тактических направления движения вперёд:<br />
# Запатчить rpm, чтобы тот при установке/обновлении/удалении пакетов определял, будет ли установлен, обновлён или удалён файл вида <tt>/usr/$d/$x</tt>, и в этом случае проводил аналогичное действие с <tt>/$d/$x</tt>, если это необходимо (автор идеи: <tt>legion@</tt>)<br />
# Попытаться соорудить вспомогательную логику на макросах, и включить её в состав {{pkg|rpm-build}}. В репозиториях без поддержки unmerged-usr эти макросы будут раскрываться в то, что нужно включить в <tt>%install</tt>, <tt>%files</tt>, <tt>%post</tt> (автор идеи: <tt>iv@</tt>; я пока считаю, что мы не потянем ручные правки такого масштаба в спеках)<br />
<br />
==== Доводы в поддержку патчить RPM ====<br />
* Патч накладывается в одном месте и решает подзадачу целиком.<br />
** Соответственно, ему легко довольно быстро пройти через сборочницу.<br />
<br />
==== Доводы против патчить RPM ====<br />
* Ваня утверждает, что генерируемые симлинки не будут никому принадлежать в смысле rpmdb или даже apt, и это невозможно изменить.<br />
<br />
==== Доводы в поддержку патчить секции спеков ====<br />
* Не нужно вникать в то, как RPM устанавливает файлы.<br />
* Ваня счёл, что пакетов, где нужно будет это сделать, немного: лишь те, которые удовлетворяют зависимостям на unmerged-usr-пути, и из их <tt>%install</tt>-секции и так придётся убирать код, перекладывающий файлы в {{path|/bin}}, etc. Этим путём пошли SuSE, но у них можно глобально на уровне сборочницы переключать ряд макросов.<br />
** <tt>glebfm@</tt> заявил, что мы можем почти так же: нам ничто не мешает переключать макросы в пакете {{pkg|rpm-build}}, разве что таким изменениям тоже нужно будет быть собранными в виде заданий и пройти все проверки.<br />
<br />
==== Доводы против патчить секции спеков ====<br />
* Не все из участников обсуждения уверены, что `%post`-скрипты, создающие файл в {{path|/bin}}, смогут правильно создать /bin/sh при установке пакета, его содержащего (может быть, в этом случае просто нужна особая логика).<br />
* Около 400 пакетов потребуется не просто исправить, но и пропустить через сборочницу. Существенную их часть будет желательно собрать либо в одной транзакции, либо хотя бы между публикациями сизифа, чтобы пакеты могли устанавливаться в сборочную среду.</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=Usrmerge/FurtherOptions&diff=75273Usrmerge/FurtherOptions2023-10-19T12:24:43Z<p>ArsenyMaslennikov: /* Требует дискуссии */</p>
<hr />
<div>Заранее приношу извинения, набирал текст второпях; надеюсь, не допустил фактических ошибок. -- arseny@<br />
<br />
=== Статус ===<br />
Сейчас у нас в пакете usrmerge есть скрипт, способный аккуратно перенести файлы и каталоги из unmerged-legacy-каталогов под /usr. Возможно, в нём потребуется переработать обработку уже существующих симлинков не вида <tt>/$x/$y <-> /usr/$x/$y</tt>. Симлинки указанного вида он восстанавливать умеет; в коде они обнаруживаются, и для них запрограммировано явное действие.<br />
<br />
=== Требует дискуссии ===<br />
В процессе подготовки базовой сборочной среды, в которой {{path|/bin}}, {{path|/sbin}} и {{path|/lib*}} являются симлинками внутрь {{path|/usr}}, обнаружилось, что:<br />
* пакеты имеют зависимости на файлы в этих каталогах, например, <tt>Requires: /bin/awk</tt>;<br />
* пути в {{path|/bin}} и проч. прописываются в hashbang генерируемых скриптов, и это не только <tt>/bin/sh</tt>;<br />
...<br />
Стало понятно, что для ручного исправления всего этого хозяйства потребуется очень много усилий, и нужно в макс. возможной степени автоматизировать переход.<br />
<br />
Пакеты можно разбить на категории сложности:<br />
# Те, что ничего не кладут в {{path|/}} и не требуют изменений.<br />
# Те, что помещают файлы или симлинки в {{path|/bin}}, {{path|/sbin}}. Сейчас это делается при помощи кода в спеках; было бы желательно автоматизировать такое размещение на обеих hier, что и предлагается обсудить.<br />
# Те, что помещают файлы в {{path|/lib/*}}. Они либо не требуют прямых изменений (потому что кладут файлы в каталог под макросом, например, `%_tmpfilesdir`, либо к каталогу, с которым они работают, нужно приписать <tt>/usr</tt>.<br />
<br />
Можно выделить два тактических направления движения вперёд:<br />
# Запатчить rpm, чтобы тот при установке/обновлении/удалении пакетов определял, будет ли установлен, обновлён или удалён файл вида <tt>/usr/$d/$x</tt>, и в этом случае проводил аналогичное действие с <tt>/$d/$x</tt>, если это необходимо (автор идеи: <tt>legion@</tt>)<br />
# Попытаться соорудить вспомогательную логику на макросах, и включить её в состав {{pkg|rpm-build}}. В репозиториях без поддержки unmerged-usr эти макросы будут раскрываться в то, что нужно включить в <tt>%install</tt>, <tt>%files</tt>, <tt>%post</tt> (автор идеи: <tt>iv@</tt>; я пока считаю, что мы не потянем ручные правки такого масштаба в спеках)<br />
<br />
==== Доводы в поддержку патчить RPM ====<br />
* Патч накладывается в одном месте и решает подзадачу целиком.<br />
** Соответственно, ему легко довольно быстро пройти через сборочницу.<br />
<br />
==== Доводы против патчить RPM ====<br />
* Ваня утверждает, что генерируемые симлинки не будут никому принадлежать в смысле rpmdb или даже apt, и это невозможно изменить.<br />
<br />
==== Доводы в поддержку патчить секции спеков ====<br />
* Не нужно вникать в то, как RPM устанавливает файлы.<br />
* Ваня счёл, что пакетов, где нужно будет это сделать, немного: лишь те, которые удовлетворяют зависимостям на unmerged-usr-пути, и из их <tt>%install</tt>-секции и так придётся убирать код, перекладывающий файлы в {{path|/bin}}, etc. Этим путём пошли SuSE, но у них можно глобально на уровне сборочницы переключать ряд макросов.<br />
** <tt>glebfm@</tt> заявил, что мы можем почти так же: нам ничто не мешает переключать макросы в пакете {{pkg|rpm-build}}, разве что таким изменениям тоже нужно будет быть собранными в виде заданий и пройти все проверки.<br />
<br />
==== Доводы против патчить секции спеков ====<br />
Не все из участников обсуждения уверены, что `%post`-скрипты, создающие файл в {{path|/bin}}, смогут правильно создать /bin/sh при установке пакета, его содержащего (может быть, в этом случае просто нужна особая логика).</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=Team/Join/Candidate&diff=75263Team/Join/Candidate2023-10-18T15:47:50Z<p>ArsenyMaslennikov: /* Создание заявки */ Замечание о том, что иногда всё-таки важно, что кандидат указывает в качестве цели</p>
<hr />
<div>Если вы считаете, что какого-то пакета в Сизифе не хватает, или что какой-то пакет заслуживает большего внимания и готовы заняться им — значит, настало время [[Team/Join|присоединиться]] к команде [[ALT Linux Team]].<br />
<br />
== Сбор информации ==<br />
<br />
Для принятия в Team необходима следующая информация:<br />
<br />
* имя ментора — участника команды, имеющего желание помогать в процессе приёма в Team. Менторов можно искать в [[Списки рассылки|списках рассылки]], канале [http://telegram.me/alt_linux Telegram] или на [[IRC]]-канале;<br />
* псевдоним (имя пользователя) участника. Выбирается им самим. Имя должно начинаться с буквы, содержать только строчные латинские буквы и цифры, быть не короче трёх символов;<br />
** Псевдоним — это фактичеcки ваше второе имя в команде. Так вас будут называть в глаза и за глаза, по нему на вас будут ссылаться. Поэтому псевдоним лучше выбирать короткий, запоминающийся и не отягощённый мусором. Например, ''yoda'' — удобный псевдоним, а ''travellingwilburys1998'' — неудобный. Список уже занятых имён можно посмотреть в пакете [http://git.altlinux.org/gears/a/alt-gpgkeys.git?p=alt-gpgkeys.git;a=tree;f=keys alt-gpgkeys]<br />
* адрес почты, на который будет производиться пересылка с адреса <tt>псевдоним@altlinux.org</tt>;<br />
* SSH-ключ (ED25519 или RSA >= 4096bit). Принимающему нужна публичная часть ключа. Этот ключ будет использоваться для SSH-доступа на ресурсы Sisyphus ([[git.alt]] и другие);<br />
* GPG-ключ (RSA >= 4096bit). В ключе должны быть имя в формате "<First name> <Last name>" и uid вида <tt>псевдоним@altlinux.org</tt>. Принимающему нужна публичная часть ключа. Этот ключ будет использоваться для подписи пакетов и для удостоверения личности в почте.<br />
<br />
Если у вас ещё нет SSH- или GPG-ключа, прочтите статью «[[Работа с ключами разработчика]]».<br />
<br />
== Создание заявки ==<br />
<br />
Заявка создаётся кандидатом в [[BugTracking/BugzillaMiniHowto|Bugzilla]]. Такие баги читает специальный член команды — секретарь.<br />
<br />
Баг должен быть оформлен следующим образом:<br />
<br />
* [http://bugzilla.altlinux.org/enter_bug.cgi?product=Team%20Accounts&component=join заведён] на компонент «join» в разделе «Development», где продуктом должен быть указан «Team Accounts»,<br />
* в теле бага нужно указать псевдоним (имя пользователя) нового участника, адрес пересылки почты, имя ментора, а также несколько слов о том, чем кандидат намерен заняться в ALT Linux Team на момент подачи заявки на вступление («собрать для начала такой-то пакет, а потом, если получится, ещё пакеты из такой-то области», «просто помочь со сборкой чего-нибудь», «научиться собирать пакеты», «у вас тут [http://bugzilla.altlinux.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=New%2Fproposed%20packages&query_format=advanced хотелка] висит» и т. п.),<br />
** '''NB''': от заявленной кандидатом цели могут зависеть, в частности, требования [[Team/Join/Mentor|ментора]] и [[Team/Join/Reviewer|рецензента]] к обретаемым кандидатом навыкам и их пристрастие.<br />
* e-mail ментора следует добавить в поле CC («Подписка»), чтобы он мог должным образом подтвердить своё менторство,<br />
* публичный SSH-ключ и публичный GPG-ключ нужно приложить к багу в виде отдельных приложений (attachments) обычными файлами. GPG-ключ необходимо приложить в экспортированном виде (<tt>gpg --export --armor <id ключа></tt>). Файлы можно прикладывать уже после создания бага.<br />
<br />
== Обработка заявки ==<br />
<br />
После получения необходимой информации секретарь проверяет приложенные ключи, создаёт e-mail адрес и выдаёт ограниченный доступ в git.alt (без возможности сборки пакетов).<br />
<br />
Помните, что и секретарь, и менторы являются добровольцами, и поэтому не всегда имеют время сразу ответить на ваши сообщения/письма/заявки — поэтому, пожалуйста, проявите терпение в случае задержки (но если не отвечают уже месяц, имеет смысл напомнить о себе).<br />
<br />
Секретарь ведёт процесс обработки заявки по [[Team/Join/Secretary|регламенту]]. При переходе на новый этап секретарь обычно указывает номер этапа в открытом кандидатом баге.<br />
<br />
== Работа с ментором ==<br />
<br />
* Ментор помогает новому участнику собирать пакеты, проверяя корректность пакетирования.<br />
* Ментор определяет момент, когда кандидат освоился с инструментарием и освоил основные правила пакетирования, после чего уведомляет об этом секретаря.<br />
* Секретарь добавляет GPG-ключ принимаемого в связку {{pkg|alt-gpgkeys}}.<br />
* С этого момента кандидат может отправлять в сборочницу тестовые задания, которые смогут попасть в репозиторий только после утверждения (approve) ментором (или любым другим членом Team).<br />
* Ментор определяет момент, когда кандидат научился совместно работать над пакетами (в частности, с ментором) и пользоваться сборочницей, и уведомляет об этом секретаря.<br />
<br />
Так как у ментора не всегда будет достаточно времени, чтобы оперативно отвечать на все вопросы, настоятельно рекомендуется подписаться на рассылку {{lists|devel-newbies}} и задавать возникающие вопросы там. Также будьте готовы к тому, что собеседник может покритиковать ваши коммиты в git, указать на ошибки; при сомнениях можно спросить, это техническая претензия или вопрос личных предпочтений (бывает и то, и другое).<br />
<br />
== Завершение процедуры ==<br />
<br />
После получения «отмашки» от ментора секретарь выдаёт полный доступ в [[git.alt]] и подписывает нового участника на {{lists|devel}}. Начиная с этого момента кандидат становится полноправным членом команды.<br />
<br />
[[Категория:Sisyphus]]<br />
[[Категория:Руководства]]<br />
{{Category navigation|title=Team|category=Team|sortkey=*}}</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=Usrmerge/FurtherOptions&diff=75261Usrmerge/FurtherOptions2023-10-18T12:52:16Z<p>ArsenyMaslennikov: Новая страница: «Заранее приношу извинения, набирал текст второпях; надеюсь, не допустил фактических ошибок. -- arseny@ === Статус === Сейчас у нас в пакете usrmerge есть скрипт, способный аккуратно перенести файлы и каталоги из unmerged-legacy-каталогов под /usr. Возможно, в нём потребуетс...»</p>
<hr />
<div>Заранее приношу извинения, набирал текст второпях; надеюсь, не допустил фактических ошибок. -- arseny@<br />
<br />
=== Статус ===<br />
Сейчас у нас в пакете usrmerge есть скрипт, способный аккуратно перенести файлы и каталоги из unmerged-legacy-каталогов под /usr. Возможно, в нём потребуется переработать обработку уже существующих симлинков не вида <tt>/$x/$y <-> /usr/$x/$y</tt>. Симлинки указанного вида он восстанавливать умеет; в коде они обнаруживаются, и для них запрограммировано явное действие.<br />
<br />
=== Требует дискуссии ===<br />
В процессе подготовки базовой сборочной среды, в которой {{path|/bin}}, {{path|/sbin}} и {{path|/lib*}} являются симлинками внутрь {{path|/usr}}, обнаружилось, что:<br />
* пакеты имеют зависимости на файлы в этих каталогах, например, <tt>Requires: /bin/awk</tt>;<br />
* пути в {{path|/bin}} и проч. прописываются в hashbang генерируемых скриптов, и это не только <tt>/bin/sh</tt>;<br />
...<br />
Стало понятно, что для ручного исправления всего этого хозяйства потребуется очень много усилий, и нужно максимально автоматизировать переход.<br />
<br />
Можно выделить два тактических направления движения вперёд:<br />
# Запатчить rpm, чтобы тот при установке/обновлении/удалении пакетов определял, будет ли установлен, обновлён или удалён файл вида <tt>/usr/$d/$x</tt>, и в этом случае проводил аналогичное действие с <tt>/$d/$x</tt>, если это необходимо (автор идеи: <tt>legion@</tt>)<br />
# Попытаться соорудить вспомогательную логику на макросах, и включить её в состав {{pkg|rpm-build}}. В репозиториях без поддержки unmerged-usr эти макросы будут раскрываться в то, что нужно включить в <tt>%install</tt>, <tt>%files</tt>, <tt>%post</tt> (автор идеи: <tt>iv@</tt>; я считаю, что мы не потянем ручные правки такого масштаба в спеках) Ваня счёл, что пакетов, где нужно будет это сделать, немного: лишь те, которые удовлетворяют зависимостям на unmerged-usr-пути. Этим путём пошли SuSE, но у них можно глобально на уровне сборочницы переключать ряд макросов. <tt>glebfm@</tt> заявил, что мы можем так же: нам ничто не мешает переключать макросы в пакете {{pkg|rpm-build}}.</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=%D0%9E%D0%B4%D0%B8%D0%BD%D0%BD%D0%B0%D0%B4%D1%86%D0%B0%D1%82%D0%B0%D1%8F_%D0%BF%D0%BB%D0%B0%D1%82%D1%84%D0%BE%D1%80%D0%BC%D0%B0&diff=74081Одиннадцатая платформа2023-09-06T12:29:09Z<p>ArsenyMaslennikov: </p>
<hr />
<div>{{Stub}}<br />
<br />
[[Категория:Branches]]<br />
[[Категория:Миграция]]<br />
<br />
Одиннадцатая платформа p11 (), новая стабильная ветка [[branches|репозиториев ALT]], созданная и развиваемая командой ALT ([[ALT Linux Team]]) в рамках проекта [[Sisyphus]], предназначена для разработки, тестирования, распространения, обновления и поддержки комплексных решений всех уровней — от встроенных устройств до серверов предприятий и датацентров. Одиннадцатая платформа будет поддерживаться [[Компания «Базальт СПО»|ООО «Базальт СПО»]].<br />
<br />
__TOC__<br />
<div id="whatsnew"></div><br />
== Что нового? ==<br />
<br />
На отдельной странице описаны нововведения с точки зрения [[Branches/p11/TechnicalNotes|продвинутых пользователей и администраторов]].<br />
<br />
=== Архитектуры Одиннадцатой платформы ===<br />
<br />
Синхронная сборка p11 производится для двух основных [[ports|архитектур]]:<br />
<br />
* 64-битных:<br />
** x86_64;<br />
** aarch64.<br />
<br />
Статус 32-битной i586 уточняется, но в репозитории для x86_64 сохранится поддержка multilib.<br />
<br />
Для 32-битных архитектур <tt>mipsel</tt>, <tt>armh</tt> (armv7a), 64-битной <tt>ppc64le</tt> бранч p11 не создаётся.<br />
<br />
Производится также сборка для трёх версий закрытой 64-битной [[эльбрус/архитектура|архитектуры "Эльбрус"]]:<br />
<br />
* e2k (v3, 4С) и e2kv4 (8С/1С+);<br />
* e2kv5 (8СВ), новой e2kv6.<br />
<br />
{{Todo|&nbsp;}}<br />
<br />
== Версии подсистем и пакетов ==<br />
Репозитории одиннадцатой платформы будут обновляться в течение срока поддержки. На момент официального анонса '''p11''' они содержат в том числе:<br />
<br />
{|class="standard"<br />
!ПО<br />
!Версия<br />
|-<br />
|Ядро Linux (std-def)||6.1.49<br />
|-<br />
|Ядро Linux (un-def)||6.4.12<br />
|-<br />
|Ядро Linux ([[OpenVZ|ovz-el7]])||???<br />
|-<br />
|[[systemd]]||254.1<br />
|-<br />
|GNU libc||2.38<br />
|-<br />
|GCC||13.1.1<br />
|-<br />
|LLVM||16.0, 17.0<br />
|-<br />
|Python||3.11.4 и 2.7.18<br />
|-<br />
|Perl||5.34.1<br />
|-<br />
|PHP||8.2<br />
|-<br />
|Ruby||2.7.3<br />
|-<br />
|Java||11.0.9.11<br />
|-<br />
|Mono||6.12.0.122<br />
|-<br />
|.NET Core||6.0<br />
|-<br />
|Node||14.17.2<br />
|-<br />
|X.Org Server||21.1.8<br />
|-<br />
|Mesa||21.1.8<br />
|-<br />
|[[GNOME]]||45<br />
|-<br />
|[[KDE]]||5.84.0<br />
|-<br />
|[[MATE]]||1.24.1<br />
|-<br />
|[[Xfce]]||4.16.0<br />
|-<br />
|[[Enlightenment]]||0.24.2<br />
|-<br />
|[[Cinnamon]]||5.0.3<br />
|-<br />
|Firefox||115.0, {{pkg|firefox-esr}} 102.13<br />
|-<br />
|LibreOffice||7.2.0.1, {{pkg|LibreOffice-still}} 7.0.6.2<br />
|-<br />
|[[Samba]]||4.14.6 (с [[SambaDC|samba-dc]])<br />
|-<br />
|Bash||5.2.15<br />
|-<br />
|[[BIND]]||9.11.32<br />
|-<br />
|CUPS||2.3.3<br />
|-<br />
|DHCP||4.4.2<br />
|-<br />
|Apache httpd||2.4.48<br />
|-<br />
|nginx||1.24.1<br />
|-<br />
|MariaDB||10.4.20<br />
|-<br />
|PostgreSQL||13.3, 12.6 для [[1C]]<br />
|-<br />
|Postfix||3.6.0<br />
|-<br />
|Dovecot||2.3.14<br />
|-<br />
|[[SOGo]]||5.1.1<br />
|-<br />
|OpenSSL||3.1.1<br />
|-<br />
|GTK+||3.24.30<br />
|-<br />
|Qt||5.15.2<br />
|-<br />
|Tomcat||9.0.45<br />
|-<br />
|[[Docker]]||20.10.7<br />
|-<br />
|[[PVE|Proxmox]]||6.3.3<br />
|-<br />
|[[Kubernetes]]||1.20.8<br />
|-<br />
|[[OpenNebula]]||5.10.5<br />
|-<br />
|[[Ansible]]||2.9.24<br />
|-<br />
|[[Puppet]]||7.9.0<br />
|}<br />
<br />
Состав и версии других пакетов можно посмотреть на сайте [http://packages.altlinux.org/ru/p11/home/ packages.altlinux.org].<br />
<br />
[[Категория:Одиннадцатая платформа]]<br />
<br />
{{Category navigation|title=Одиннадцатая платформа|category=Одиннадцатая платформа}}</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=%D0%9E%D0%B4%D0%B8%D0%BD%D0%BD%D0%B0%D0%B4%D1%86%D0%B0%D1%82%D0%B0%D1%8F_%D0%BF%D0%BB%D0%B0%D1%82%D1%84%D0%BE%D1%80%D0%BC%D0%B0&diff=73755Одиннадцатая платформа2023-08-29T14:08:14Z<p>ArsenyMaslennikov: /* Версии подсистем и пакетов */</p>
<hr />
<div>{{Stub}}<br />
<br />
[[Категория:Branches]]<br />
[[Категория:Миграция]]<br />
<br />
Одиннадцатая платформа p11 (), новая стабильная ветка [[branches|репозиториев ALT]], предназначена для разработки, тестирования, распространения, обновления и поддержки комплексных решений всех уровней — от встроенных устройств до серверов предприятий и датацентров, созданная и развиваемая командой ALT ([[ALT Linux Team]]) в рамках проекта [[Sisyphus]]. Одиннадцатая платформа будет поддерживаться [[Компания «Базальт СПО»|ООО «Базальт СПО»]].<br />
<br />
__TOC__<br />
<div id="whatsnew"></div><br />
== Что нового? ==<br />
<br />
На отдельной странице описаны нововведения с точки зрения [[Branches/p11/TechnicalNotes|продвинутых пользователей и администраторов]].<br />
<br />
=== Архитектуры Одиннадцатой платформы ===<br />
<br />
Синхронная сборка p11 производится для трёх основных [[ports|архитектур]]:<br />
<br />
* 64-битных x86_64, aarch64;<br />
* 32-битной i586<br />
<br />
Для 32-битной архитектуры mipsel бранч p11 не создаётся.<br />
<br />
Производится также сборка для трёх версий закрытой 64-битной [[эльбрус/архитектура|архитектуры "Эльбрус"]]:<br />
<br />
* e2k (v3, 4С) и e2kv4 (8С/1С+);<br />
* e2kv5 (8СВ), новой e2kv6.<br />
<br />
{{Todo|&nbsp;}}<br />
<br />
== Версии подсистем и пакетов ==<br />
Репозитории одиннадцатой платформы будут обновляться в течение срока поддержки. На момент официального анонса '''p11''' они содержат в том числе:<br />
<br />
{|class="standard"<br />
!ПО<br />
!Версия<br />
|-<br />
|Ядро Linux (std-def)||6.1.49<br />
|-<br />
|Ядро Linux (un-def)||6.4.12<br />
|-<br />
|Ядро Linux ([[OpenVZ|ovz-el7]])||???<br />
|-<br />
|[[systemd]]||254.1<br />
|-<br />
|GNU libc||2.38<br />
|-<br />
|GCC||13.1.1<br />
|-<br />
|LLVM||15.0, 16.0<br />
|-<br />
|Python||3.11.4 и 2.7.18<br />
|-<br />
|Perl||5.34.1<br />
|-<br />
|PHP||8.2<br />
|-<br />
|Ruby||2.7.3<br />
|-<br />
|Java||11.0.9.11<br />
|-<br />
|Mono||6.12.0.122<br />
|-<br />
|.NET Core||6.0<br />
|-<br />
|Node||14.17.2<br />
|-<br />
|X.Org Server||21.1.8<br />
|-<br />
|Mesa||21.1.8<br />
|-<br />
|[[GNOME]]||44.3<br />
|-<br />
|[[KDE]]||5.84.0<br />
|-<br />
|[[MATE]]||1.24.1<br />
|-<br />
|[[Xfce]]||4.16.0<br />
|-<br />
|[[Enlightenment]]||0.24.2<br />
|-<br />
|[[Cinnamon]]||5.0.3<br />
|-<br />
|Firefox||115.0, {{pkg|firefox-esr}} ???<br />
|-<br />
|LibreOffice||7.2.0.1, {{pkg|LibreOffice-still}} 7.0.6.2<br />
|-<br />
|[[Samba]]||4.14.6 (с [[SambaDC|samba-dc]])<br />
|-<br />
|Bash||???<br />
|-<br />
|[[BIND]]||9.11.32<br />
|-<br />
|CUPS||2.3.3<br />
|-<br />
|DHCP||4.4.2<br />
|-<br />
|Apache httpd||2.4.48<br />
|-<br />
|nginx||1.24.1<br />
|-<br />
|MariaDB||10.4.20<br />
|-<br />
|PostgreSQL||13.3, 12.6 для [[1C]]<br />
|-<br />
|Postfix||3.6.0<br />
|-<br />
|Dovecot||2.3.14<br />
|-<br />
|[[SOGo]]||5.1.1<br />
|-<br />
|OpenSSL||3.1.1<br />
|-<br />
|GTK+||3.24.30<br />
|-<br />
|Qt||5.15.2<br />
|-<br />
|Tomcat||9.0.45<br />
|-<br />
|[[Docker]]||20.10.7<br />
|-<br />
|[[PVE|Proxmox]]||6.3.3<br />
|-<br />
|[[Kubernetes]]||1.20.8<br />
|-<br />
|[[OpenNebula]]||5.10.5<br />
|-<br />
|[[Ansible]]||2.9.24<br />
|-<br />
|[[Puppet]]||7.9.0<br />
|}<br />
<br />
Состав и версии других пакетов можно посмотреть на сайте [http://packages.altlinux.org/ru/p11/home/ packages.altlinux.org].<br />
<br />
[[Категория:Одиннадцатая платформа]]<br />
<br />
{{Category navigation|title=Одиннадцатая платформа|category=Одиннадцатая платформа}}</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=%D0%9E%D0%B4%D0%B8%D0%BD%D0%BD%D0%B0%D0%B4%D1%86%D0%B0%D1%82%D0%B0%D1%8F_%D0%BF%D0%BB%D0%B0%D1%82%D1%84%D0%BE%D1%80%D0%BC%D0%B0&diff=73744Одиннадцатая платформа2023-08-28T15:49:34Z<p>ArsenyMaslennikov: include e2kv6, update kernel revisions</p>
<hr />
<div>{{Stub}}<br />
<br />
[[Категория:Branches]]<br />
[[Категория:Миграция]]<br />
<br />
Одиннадцатая платформа p11 (), новая стабильная ветка [[branches|репозиториев ALT]], предназначена для разработки, тестирования, распространения, обновления и поддержки комплексных решений всех уровней — от встроенных устройств до серверов предприятий и датацентров, созданная и развиваемая командой ALT ([[ALT Linux Team]]) в рамках проекта [[Sisyphus]]. Одиннадцатая платформа будет поддерживаться [[Компания «Базальт СПО»|ООО «Базальт СПО»]].<br />
<br />
__TOC__<br />
<div id="whatsnew"></div><br />
== Что нового? ==<br />
<br />
На отдельной странице описаны нововведения с точки зрения [[Branches/p11/TechnicalNotes|продвинутых пользователей и администраторов]].<br />
<br />
=== Архитектуры Одиннадцатой платформы ===<br />
<br />
Синхронная сборка p11 производится для трёх основных [[ports|архитектур]]:<br />
<br />
* 64-битных x86_64, aarch64;<br />
* 32-битной i586<br />
<br />
Для 32-битной архитектуры mipsel бранч p11 не создаётся.<br />
<br />
Производится также сборка для трёх версий закрытой 64-битной [[эльбрус/архитектура|архитектуры "Эльбрус"]]:<br />
<br />
* e2k (v3, 4С) и e2kv4 (8С/1С+);<br />
* e2kv5 (8СВ), новой e2kv6.<br />
<br />
{{Todo|&nbsp;}}<br />
<br />
== Версии подсистем и пакетов ==<br />
Репозитории одиннадцатой платформы будут обновляться в течение срока поддержки. На момент официального анонса '''p11''' они содержат в том числе:<br />
<br />
{|class="standard"<br />
!ПО<br />
!Версия<br />
|-<br />
|Ядро Linux (std-def)||6.1.49<br />
|-<br />
|Ядро Linux (un-def)||6.4.12<br />
|-<br />
|Ядро Linux ([[OpenVZ|ovz-el7]])||???<br />
|-<br />
|[[systemd]]||254.1<br />
|-<br />
|GNU libc||2.38<br />
|-<br />
|GCC||13.1.1<br />
|-<br />
|LLVM||15.0, 16.0<br />
|-<br />
|Python||3.11.4 и 2.7.18<br />
|-<br />
|Perl||5.34.1<br />
|-<br />
|PHP||8.0.8<br />
|-<br />
|Ruby||2.7.3<br />
|-<br />
|Java||11.0.9.11<br />
|-<br />
|Mono||6.12.0.122<br />
|-<br />
|.NET Core||6.0<br />
|-<br />
|Node||14.17.2<br />
|-<br />
|X.Org Server||21.1.8<br />
|-<br />
|Mesa||21.1.8<br />
|-<br />
|[[GNOME]]||44.3<br />
|-<br />
|[[KDE]]||5.84.0<br />
|-<br />
|[[MATE]]||1.24.1<br />
|-<br />
|[[Xfce]]||4.16.0<br />
|-<br />
|[[Enlightenment]]||0.24.2<br />
|-<br />
|[[Cinnamon]]||5.0.3<br />
|-<br />
|Firefox||115.0, {{pkg|firefox-esr}} ???<br />
|-<br />
|LibreOffice||7.2.0.1, {{pkg|LibreOffice-still}} 7.0.6.2<br />
|-<br />
|[[Samba]]||4.14.6 (с [[SambaDC|samba-dc]])<br />
|-<br />
|Bash||???<br />
|-<br />
|[[BIND]]||9.11.32<br />
|-<br />
|CUPS||2.3.3<br />
|-<br />
|DHCP||4.4.2<br />
|-<br />
|Apache httpd||2.4.48<br />
|-<br />
|nginx||1.24.1<br />
|-<br />
|MariaDB||10.4.20<br />
|-<br />
|PostgreSQL||13.3, 12.6 для [[1C]]<br />
|-<br />
|Postfix||3.6.0<br />
|-<br />
|Dovecot||2.3.14<br />
|-<br />
|[[SOGo]]||5.1.1<br />
|-<br />
|OpenSSL||3.1.1<br />
|-<br />
|GTK+||3.24.30<br />
|-<br />
|Qt||5.15.2<br />
|-<br />
|Tomcat||9.0.45<br />
|-<br />
|[[Docker]]||20.10.7<br />
|-<br />
|[[PVE|Proxmox]]||6.3.3<br />
|-<br />
|[[Kubernetes]]||1.20.8<br />
|-<br />
|[[OpenNebula]]||5.10.5<br />
|-<br />
|[[Ansible]]||2.9.24<br />
|-<br />
|[[Puppet]]||7.9.0<br />
|}<br />
<br />
Состав и версии других пакетов можно посмотреть на сайте [http://packages.altlinux.org/ru/p11/home/ packages.altlinux.org].<br />
<br />
[[Категория:Одиннадцатая платформа]]<br />
<br />
{{Category navigation|title=Одиннадцатая платформа|category=Одиннадцатая платформа}}</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=%D0%9E%D0%B4%D0%B8%D0%BD%D0%BD%D0%B0%D0%B4%D1%86%D0%B0%D1%82%D0%B0%D1%8F_%D0%BF%D0%BB%D0%B0%D1%82%D1%84%D0%BE%D1%80%D0%BC%D0%B0&diff=73696Одиннадцатая платформа2023-08-26T22:12:05Z<p>ArsenyMaslennikov: /* Архитектуры Одиннадцатой платформы */</p>
<hr />
<div>{{Stub}}<br />
<br />
[[Категория:Branches]]<br />
[[Категория:Миграция]]<br />
<br />
Одиннадцатая платформа p11 (), новая стабильная ветка [[branches|репозиториев ALT]], предназначена для разработки, тестирования, распространения, обновления и поддержки комплексных решений всех уровней — от встроенных устройств до серверов предприятий и датацентров, созданная и развиваемая командой ALT ([[ALT Linux Team]]) в рамках проекта [[Sisyphus]]. Одиннадцатая платформа будет поддерживаться [[Компания «Базальт СПО»|ООО «Базальт СПО»]].<br />
<br />
__TOC__<br />
<div id="whatsnew"></div><br />
== Что нового? ==<br />
<br />
На отдельной странице описаны нововведения с точки зрения [[Branches/p11/TechnicalNotes|продвинутых пользователей и администраторов]].<br />
<br />
=== Архитектуры Одиннадцатой платформы ===<br />
<br />
Синхронная сборка p11 производится для трёх основных [[ports|архитектур]]:<br />
<br />
* 64-битных x86_64, aarch64;<br />
* 32-битной i586<br />
<br />
Для 32-битной архитектуры mipsel бранч p11 не создаётся.<br />
<br />
Производится также сборка для трёх версий закрытой 64-битной [[эльбрус/архитектура|архитектуры "Эльбрус"]]:<br />
<br />
* e2k (v3, 4С) и e2kv4 (8С/1С+);<br />
* новой e2kv5 (8СВ).<br />
<br />
{{Todo|&nbsp;}}<br />
<br />
== Версии подсистем и пакетов ==<br />
Репозитории одиннадцатой платформы будут обновляться в течение срока поддержки. На момент официального анонса '''p11''' они содержат в том числе:<br />
<br />
{|class="standard"<br />
!ПО<br />
!Версия<br />
|-<br />
|Ядро Linux (std-def)||6.4.12<br />
|-<br />
|Ядро Linux (un-def)||6.4.12<br />
|-<br />
|Ядро Linux ([[OpenVZ|ovz-el7]])||???<br />
|-<br />
|[[systemd]]||254.1<br />
|-<br />
|GNU libc||2.38<br />
|-<br />
|GCC||13.1.1<br />
|-<br />
|LLVM||15.0, 16.0<br />
|-<br />
|Python||3.11.4 и 2.7.18<br />
|-<br />
|Perl||5.34.1<br />
|-<br />
|PHP||8.0.8<br />
|-<br />
|Ruby||2.7.3<br />
|-<br />
|Java||11.0.9.11<br />
|-<br />
|Mono||6.12.0.122<br />
|-<br />
|.NET Core||6.0<br />
|-<br />
|Node||14.17.2<br />
|-<br />
|X.Org Server||21.1.8<br />
|-<br />
|Mesa||21.1.8<br />
|-<br />
|[[GNOME]]||44.3<br />
|-<br />
|[[KDE]]||5.84.0<br />
|-<br />
|[[MATE]]||1.24.1<br />
|-<br />
|[[Xfce]]||4.16.0<br />
|-<br />
|[[Enlightenment]]||0.24.2<br />
|-<br />
|[[Cinnamon]]||5.0.3<br />
|-<br />
|Firefox||115.0, {{pkg|firefox-esr}} ???<br />
|-<br />
|LibreOffice||7.2.0.1, {{pkg|LibreOffice-still}} 7.0.6.2<br />
|-<br />
|[[Samba]]||4.14.6 (с [[SambaDC|samba-dc]])<br />
|-<br />
|Bash||???<br />
|-<br />
|[[BIND]]||9.11.32<br />
|-<br />
|CUPS||2.3.3<br />
|-<br />
|DHCP||4.4.2<br />
|-<br />
|Apache httpd||2.4.48<br />
|-<br />
|nginx||1.24.1<br />
|-<br />
|MariaDB||10.4.20<br />
|-<br />
|PostgreSQL||13.3, 12.6 для [[1C]]<br />
|-<br />
|Postfix||3.6.0<br />
|-<br />
|Dovecot||2.3.14<br />
|-<br />
|[[SOGo]]||5.1.1<br />
|-<br />
|OpenSSL||3.1.1<br />
|-<br />
|GTK+||3.24.30<br />
|-<br />
|Qt||5.15.2<br />
|-<br />
|Tomcat||9.0.45<br />
|-<br />
|[[Docker]]||20.10.7<br />
|-<br />
|[[PVE|Proxmox]]||6.3.3<br />
|-<br />
|[[Kubernetes]]||1.20.8<br />
|-<br />
|[[OpenNebula]]||5.10.5<br />
|-<br />
|[[Ansible]]||2.9.24<br />
|-<br />
|[[Puppet]]||7.9.0<br />
|}<br />
<br />
Состав и версии других пакетов можно посмотреть на сайте [http://packages.altlinux.org/ru/p11/home/ packages.altlinux.org].<br />
<br />
[[Категория:Одиннадцатая платформа]]<br />
<br />
{{Category navigation|title=Одиннадцатая платформа|category=Одиннадцатая платформа}}</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=%D0%9E%D0%B4%D0%B8%D0%BD%D0%BD%D0%B0%D0%B4%D1%86%D0%B0%D1%82%D0%B0%D1%8F_%D0%BF%D0%BB%D0%B0%D1%82%D1%84%D0%BE%D1%80%D0%BC%D0%B0&diff=73695Одиннадцатая платформа2023-08-26T22:11:23Z<p>ArsenyMaslennikov: /* Версии подсистем и пакетов */</p>
<hr />
<div>{{Stub}}<br />
<br />
[[Категория:Branches]]<br />
[[Категория:Миграция]]<br />
<br />
Одиннадцатая платформа p11 (), новая стабильная ветка [[branches|репозиториев ALT]], предназначена для разработки, тестирования, распространения, обновления и поддержки комплексных решений всех уровней — от встроенных устройств до серверов предприятий и датацентров, созданная и развиваемая командой ALT ([[ALT Linux Team]]) в рамках проекта [[Sisyphus]]. Одиннадцатая платформа будет поддерживаться [[Компания «Базальт СПО»|ООО «Базальт СПО»]].<br />
<br />
__TOC__<br />
<div id="whatsnew"></div><br />
== Что нового? ==<br />
<br />
На отдельной странице описаны нововведения с точки зрения [[Branches/p11/TechnicalNotes|продвинутых пользователей и администраторов]].<br />
<br />
=== Архитектуры Одиннадцатой платформы ===<br />
<br />
Синхронная сборка p11 производится для пяти основных [[ports|архитектур]]:<br />
<br />
* 64-битных x86_64, aarch64;<br />
* 32-битной i586<br />
<br />
Для 32-битной архитектуры mipsel бранч p11 не создаётся.<br />
<br />
Производится также сборка для трёх версий закрытой 64-битной [[эльбрус/архитектура|архитектуры "Эльбрус"]]:<br />
<br />
* e2k (v3, 4С) и e2kv4 (8С/1С+);<br />
* новой e2kv5 (8СВ).<br />
<br />
{{Todo|&nbsp;}}<br />
<br />
== Версии подсистем и пакетов ==<br />
Репозитории одиннадцатой платформы будут обновляться в течение срока поддержки. На момент официального анонса '''p11''' они содержат в том числе:<br />
<br />
{|class="standard"<br />
!ПО<br />
!Версия<br />
|-<br />
|Ядро Linux (std-def)||6.4.12<br />
|-<br />
|Ядро Linux (un-def)||6.4.12<br />
|-<br />
|Ядро Linux ([[OpenVZ|ovz-el7]])||???<br />
|-<br />
|[[systemd]]||254.1<br />
|-<br />
|GNU libc||2.38<br />
|-<br />
|GCC||13.1.1<br />
|-<br />
|LLVM||15.0, 16.0<br />
|-<br />
|Python||3.11.4 и 2.7.18<br />
|-<br />
|Perl||5.34.1<br />
|-<br />
|PHP||8.0.8<br />
|-<br />
|Ruby||2.7.3<br />
|-<br />
|Java||11.0.9.11<br />
|-<br />
|Mono||6.12.0.122<br />
|-<br />
|.NET Core||6.0<br />
|-<br />
|Node||14.17.2<br />
|-<br />
|X.Org Server||21.1.8<br />
|-<br />
|Mesa||21.1.8<br />
|-<br />
|[[GNOME]]||44.3<br />
|-<br />
|[[KDE]]||5.84.0<br />
|-<br />
|[[MATE]]||1.24.1<br />
|-<br />
|[[Xfce]]||4.16.0<br />
|-<br />
|[[Enlightenment]]||0.24.2<br />
|-<br />
|[[Cinnamon]]||5.0.3<br />
|-<br />
|Firefox||115.0, {{pkg|firefox-esr}} ???<br />
|-<br />
|LibreOffice||7.2.0.1, {{pkg|LibreOffice-still}} 7.0.6.2<br />
|-<br />
|[[Samba]]||4.14.6 (с [[SambaDC|samba-dc]])<br />
|-<br />
|Bash||???<br />
|-<br />
|[[BIND]]||9.11.32<br />
|-<br />
|CUPS||2.3.3<br />
|-<br />
|DHCP||4.4.2<br />
|-<br />
|Apache httpd||2.4.48<br />
|-<br />
|nginx||1.24.1<br />
|-<br />
|MariaDB||10.4.20<br />
|-<br />
|PostgreSQL||13.3, 12.6 для [[1C]]<br />
|-<br />
|Postfix||3.6.0<br />
|-<br />
|Dovecot||2.3.14<br />
|-<br />
|[[SOGo]]||5.1.1<br />
|-<br />
|OpenSSL||3.1.1<br />
|-<br />
|GTK+||3.24.30<br />
|-<br />
|Qt||5.15.2<br />
|-<br />
|Tomcat||9.0.45<br />
|-<br />
|[[Docker]]||20.10.7<br />
|-<br />
|[[PVE|Proxmox]]||6.3.3<br />
|-<br />
|[[Kubernetes]]||1.20.8<br />
|-<br />
|[[OpenNebula]]||5.10.5<br />
|-<br />
|[[Ansible]]||2.9.24<br />
|-<br />
|[[Puppet]]||7.9.0<br />
|}<br />
<br />
Состав и версии других пакетов можно посмотреть на сайте [http://packages.altlinux.org/ru/p11/home/ packages.altlinux.org].<br />
<br />
[[Категория:Одиннадцатая платформа]]<br />
<br />
{{Category navigation|title=Одиннадцатая платформа|category=Одиннадцатая платформа}}</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=Usrmerge&diff=72047Usrmerge2023-08-02T11:05:11Z<p>ArsenyMaslennikov: /* Rationale */</p>
<hr />
<div>[[Категория:Sisyphus]]<br />
<br />
= Usrmerge =<br />
'''''Точный план действий сейчас вырабатывается, и его подробности могут измениться.'''''<br />
Статус воплощения отслеживается в {{altbug|46738}}.<br />
<br />
== Введение ==<br />
Исторически<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|/}}, содержащего все эти подкаталоги.<br />
<br />
Позже, с увеличением средних размеров устройств хранения в машинах, сторонники разделения придумали другие обоснования (например, возможность из окружения в {{path|/{bin,sbin,libX,...}/}} починить немонтирующуюся {{path|/usr}}). Но на сегодняшний день непонятно, какой набор утилит и нужных им so/иных файлов стоит признать частью "системы спасения", которая должна быть доступна без {{path|/usr}}, а какой — нет, ибо сами утилиты приобретают универсальный вид и широкие границы применимости. С развитием механизмов initramfs и живых загрузочных/установочных носителей, а также практикой "раздела восстановления" на локальном хранилище машины среди настольных дистрибутивов этот аргумент теряет всякий смысл.<br />
<br />
Чем сохранять бесцельно дублирующие друг друга два класса мест для одних и тех же файлов, лучше оставить один из них, а другой устранить:<br />
* либо переложить {{path|/usr/{bin,sbin,lib,libx32,lib64,libexec,local,share,src,...}}} в корень,<br />
* либо поместить аналоги этих каталогов из {{path|/}} в {{path|/usr}}.<br />
<br />
Из двух вариантов, входящих в рамки FHS<ref>[https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf]</ref>, второй лучше хотя бы тем, что уменьшает количество top-level каталогов, куда упаковывается постоянное содержимое пакетов, до одного. Сейчас среди FHS-совместимых дистрибутивов это типичный подход, на который в том числе потихоньку начинают полагаться апстримы прикладных пакетов.<br />
<br />
== Rationale ==<br />
* Один каталог (пусть с не очень удачным именем {{path|/usr}}) как объект манипуляции и как общий носитель фиксированного содержимого пакетов удобнее россыпи каталогов, полный список которых даже невозможно построить. Появляется даже смысл рассматривать его в виде отдельной точки монтирования, которую можно держать общей на многих машинах под общим управлением.<br />
** Один каталог легче снапшотить, по нему легче гонять {{cmd|find}}, ...<br />
* Упаковка всего пакетного содержимого в {{path|/usr}} открывает дорогу к виртуальному {{path|/}}, который не находится на устройстве хранения и содержит только пустые каталоги-точки-монтирования.<br />
* Возникает осмысленное разделение между {{path|/usr}}, {{path|/var}} и {{path|/etc}}: первый каталог несёт в себе постоянное содержимое пакетов, не предназначенное к ручной модификации (не через пакетную систему или доставку образа), а другие два уже исторически применяются для переменного хранимого состояния и общесистемных конфигов.<br />
* Сборочным скриптам и прочим интеграционным программным компонентам не нужно будет перебирать каталоги, в которых находится искомая программа.<ref>Вообще-то для этого нужно ещё провести слияние sbin и bin, но оно не несёт срочности и не рассматривается на этой странице.</ref><br />
* Начиная с версии 255, планируемой к выпуску в течение 2023, {{pkg|systemd}} [https://lists.freedesktop.org/archives/systemd-devel/2022-April/047673.html прекратит] поддержку split-usr и unmerged-usr; вот [https://github.com/systemd/systemd/pull/27999/commits/cedcd0bc61913db1e37e19f00d3f97fc72436728 коммит].<br />
** Из кода проекта {{pkg|systemd}}, помимо прочего, исчезнут все упоминания старых каталогов; например, директива <tt>ProtectKernelModules=</tt> больше не будет монтировать заглушку поверх <tt>/lib/modules</tt>, и т. п.<br />
<br />
== Proposed changes ==<br />
Необходимые действия можно разбить на две стадии.<br />
<br />
=== Стадия 1 ===<br />
* На стадии brp завершаться с ошибкой, если обнаружены разные файлы в {{path|/bin/x}} и {{path|/usr/bin/x}}, ...<br />
<br />
1. Определить, что слиянию с аналогами внутри /usr подлежат следующие каталоги:<br />
<pre><br />
/bin<br />
/lib<br />
/lib32<br />
/lib64<br />
/libx32<br />
/sbin<br />
</pre><br />
На каждой машине есть некоторые каталоги из этого списка; они и будут перенесены.<br />
<br />
2. Тем или иным образом научить rpm создавать симлинк вида<br />
<pre><br />
/bin/x -> ../usr/bin/x<br />
</pre><br />
..., если в пакете существует {{path|/usr/bin/x}} и <tt>Provides: /bin/x</tt>. Аналогично для всех каталогов из списка 1. Таким образом, на переходном этапе будет не нужно указывать в <tt>%files</tt> пакетов все эти симлинки, чтобы потом их убирать, и пакеты продолжат удовлетворять зависимостям на такие файлы.<br />
<br />
Важно, чтобы сначала удалялся старый путь, как обычно при установке<br />
пакета, а симлинк возникал после этой фазы.<br />
<br />
2.1) Бекпортировать поддержку в p10.<br />
<br />
3) Подготовить пакет {{pkg|filesystem}} версии 3: поместить в нём файлтриггер,<br />
который проверяет, не состоят ли каталоги из списка 1 целиком из<br />
симлинков внутрь {{path|/usr}}, и превращает такой каталог с симлинками в симлинк<br />
на каталог.<br />
Сценарий файлтриггера должен будет давать предельно ясную информацию и<br />
диагностические сообщения на стандартные потоки. Нужно будет либо<br />
положиться на static coreutils, либо очень осторожно обращаться с<br />
обычными и dynamic linker.<br />
<br />
4) Заменить макросы, использующие старые каталоги (<tt>%_udevrulesdir</tt>,<br />
<tt>%_tmpfilesdir</tt> и другие), и пересобрать с ними пакеты, что-либо<br />
помещающие в эти каталоги.<br />
Приближённое число затрагиваемых бинарных пакетов:<br />
<pre><br />
% grep -E '^/(bin|lib[^/]*|sbin)/[a-z0-9_-]+' contents-index \<br />
| grep -vE '^/lib/(systemd|udev|sysusers.d|modules[^/]*|modprobe.d|security|tmpfiles.d)'<br />
\ # exclude known places<br />
| cut -f2 -d$'\t' | grep -v '^/' # exclude path provides<br />
| sort | uniq | wc -l<br />
528<br />
</pre><br />
Это оценка по x86_64 + noarch. Исходных, конечно, будет меньше.<br />
<br />
При обновлении на эти пакеты будет действовать правило 2, поэтому их<br />
содержимое будет доступно.<br />
<br />
Некоторые пакеты, например, {{pkg|vim-common}}, сейчас упаковывают разные<br />
файловые объекты в {{path|/bin}} и {{path|/usr/bin}}; другие пакеты ставят файлы прямо<br />
в {{path|%buildroot/bin}}. Их потребуется исправить руками. (Справедливости ради,<br />
многие из них и так понадобится обновить)<br />
<br />
=== Стадия 2 ===<br />
Этот пункт вступает в действие на каждой машине индивидуально при<br />
обновлении её пакетов.<br />
Файлтриггер из пункта 3 обнаруживает, что можно ввести симлинки, и<br />
делает это, завершая процесс usrmerge на данной системе.<br />
<br />
Каждая инсталляция перейдёт к ней независимо, как только все пакеты в этой инсталляции будут содержать свои файлы под {{path|/usr}}.<br />
<br />
== Incompatibilities ==<br />
<br />
Если корневая файловая система — каскадная композиция на базе, например, overlayfs, и каталоги {{path|/bin}} и подобные находятся ''не в верхнем'' слое стека — автоматически обновить такую корневую файловую систему на {{pkg|filesystem > 3}} '''не выйдет'''. Придётся либо не обновляться, либо пересобрать контейнер/систему на обновлённой пакетной базе.<br />
<br />
== FAQ ==<br />
<br />
Рекомендуем прочитать другие материалы о преимуществах предлагаемого решения<ref>[https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ TheCaseForTheUsrMerge]</ref><ref>[https://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/ separate-usr-is-broken], примеры, где в ранней системе полагаются на наличие {{path|/usr}}}</ref>.<br />
<br />
'''Q: А что, если {{path|/usr}} на отдельном разделе по каким-то причинам не примонтируется?'''<br />
<br />
A: Тогда система не сможет загрузиться, как и в случае, если {{path|/}} по каким-то причинам не примонтируется.<br />
<br />
'''Q: А раньше можно было, пользуясь программами в {{path|/}}, починить {{path|/usr}}'''<br />
<br />
A: Несколько тезисов:<br />
* В-нулевых, для того, чтобы возникла такая ситуация, систему должны были установить так, чтобы {{path|/usr}} был отдельным от {{path|/}}, т. е. такая разметка преследовала какую-либо цель.<br />
* Во-первых, для этого нужно, чтобы {{path|/}} '''смог''' смонтироваться, а {{path|/usr}} '''не смог'''.<br />
* Во-вторых, всё ещё нет критерия, по которому ту или иную программу и её зависимости можно либо отнести к "системе спасения", либо исключить из неё и сослать в {{path|/usr}}.<br />
* В-третьих, нет ни одного задокументированного случая, где таким образом спасли какую-либо типичную GNU/Linux-систему, включая Альт, есть только [https://www.ecb.torontomu.ca/~elf/hack/recovery.html предание] из 1986 года, касавшееся non-Linux тех времён на компьютере тех времён. Рецептов такого восстановления, отчуждаемых от компетенций разработчиков ALT и умелых сисадминов, нет тем более. Следовательно, можно заключить, что в общем случае цитируемая возможность восстановить {{path|/usr}} из {{path|/}} — призрачна.<br />
* Несмотря на всё это, нет ничего плохого в том, чтобы рецепт такого спасения (при помощи операционной избыточности инсталляции альта) администратору ''предложить'', но это должен быть явный механизм с минимумом издержек для остальной структуры системы. Есть множество вариантов это реализовать с разными преимуществами и минусами в разных установках; все они out of scope for this document.<br />
<br />
== User-visible impact ==<br />
Меньше каталогов верхнего уровня в корне, кроме симлинков.<br />
<br />
== Appendix ==</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=%D0%9E%D0%B4%D0%B8%D0%BD%D0%BD%D0%B0%D0%B4%D1%86%D0%B0%D1%82%D0%B0%D1%8F_%D0%BF%D0%BB%D0%B0%D1%82%D1%84%D0%BE%D1%80%D0%BC%D0%B0&diff=71621Одиннадцатая платформа2023-07-26T13:44:04Z<p>ArsenyMaslennikov: /* Архитектуры Одиннадцатой платформы */</p>
<hr />
<div>{{Stub}}<br />
<br />
[[Категория:Branches]]<br />
[[Категория:Миграция]]<br />
<br />
Одиннадцатая платформа p11 (), новая стабильная ветка [[branches|репозиториев ALT]], предназначена для разработки, тестирования, распространения, обновления и поддержки комплексных решений всех уровней — от встроенных устройств до серверов предприятий и датацентров, созданная и развиваемая командой ALT ([[ALT Linux Team]]) в рамках проекта [[Sisyphus]]. Одиннадцатая платформа будет поддерживаться [[Компания «Базальт СПО»|ООО «Базальт СПО»]].<br />
<br />
__TOC__<br />
<div id="whatsnew"></div><br />
== Что нового? ==<br />
<br />
На отдельной странице описаны нововведения с точки зрения [[Branches/p11/TechnicalNotes|продвинутых пользователей и администраторов]].<br />
<br />
=== Архитектуры Одиннадцатой платформы ===<br />
<br />
Синхронная сборка p11 производится для пяти основных [[ports|архитектур]]:<br />
<br />
* 64-битных x86_64, aarch64;<br />
* 32-битной i586<br />
<br />
Для 32-битной архитектуры mipsel бранч p11 не создаётся.<br />
<br />
Производится также сборка для трёх версий закрытой 64-битной [[эльбрус/архитектура|архитектуры "Эльбрус"]]:<br />
<br />
* e2k (v3, 4С) и e2kv4 (8С/1С+);<br />
* новой e2kv5 (8СВ).<br />
<br />
{{Todo|&nbsp;}}<br />
<br />
== Версии подсистем и пакетов ==<br />
Репозитории одиннадцатой платформы будут обновляться в течение срока поддержки. На момент официального анонса '''p11''' они содержат в том числе:<br />
<br />
{|class="standard"<br />
!ПО<br />
!Версия<br />
|-<br />
|Ядро Linux (std-def)||6.3.8<br />
|-<br />
|Ядро Linux (un-def)||6.3.8<br />
|-<br />
|Ядро Linux ([[OpenVZ|ovz-el7]])||???<br />
|-<br />
|[[systemd]]||254.1<br />
|-<br />
|GNU libc||2.38<br />
|-<br />
|GCC||13.1.1<br />
|-<br />
|LLVM||15.0, 16.0<br />
|-<br />
|Python||3.11.4 и 2.7.18<br />
|-<br />
|Perl||5.34.1<br />
|-<br />
|PHP||8.0.8<br />
|-<br />
|Ruby||2.7.3<br />
|-<br />
|Java||11.0.9.11<br />
|-<br />
|Mono||6.12.0.122<br />
|-<br />
|.NET Core||6.0<br />
|-<br />
|Node||14.17.2<br />
|-<br />
|X.Org Server||21.1.8<br />
|-<br />
|Mesa||21.1.8<br />
|-<br />
|[[GNOME]]||44.3<br />
|-<br />
|[[KDE]]||5.84.0<br />
|-<br />
|[[MATE]]||1.24.1<br />
|-<br />
|[[Xfce]]||4.16.0<br />
|-<br />
|[[Enlightenment]]||0.24.2<br />
|-<br />
|[[Cinnamon]]||5.0.3<br />
|-<br />
|Firefox||115.0, {{pkg|firefox-esr}} ???<br />
|-<br />
|LibreOffice||7.2.0.1, {{pkg|LibreOffice-still}} 7.0.6.2<br />
|-<br />
|[[Samba]]||4.14.6 (с [[SambaDC|samba-dc]])<br />
|-<br />
|Bash||???<br />
|-<br />
|[[BIND]]||9.11.32<br />
|-<br />
|CUPS||2.3.3<br />
|-<br />
|DHCP||4.4.2<br />
|-<br />
|Apache httpd||2.4.48<br />
|-<br />
|nginx||1.24.1<br />
|-<br />
|MariaDB||10.4.20<br />
|-<br />
|PostgreSQL||13.3, 12.6 для [[1C]]<br />
|-<br />
|Postfix||3.6.0<br />
|-<br />
|Dovecot||2.3.14<br />
|-<br />
|[[SOGo]]||5.1.1<br />
|-<br />
|OpenSSL||3.1.1<br />
|-<br />
|GTK+||3.24.30<br />
|-<br />
|Qt||5.15.2<br />
|-<br />
|Tomcat||9.0.45<br />
|-<br />
|[[Docker]]||20.10.7<br />
|-<br />
|[[PVE|Proxmox]]||6.3.3<br />
|-<br />
|[[Kubernetes]]||1.20.8<br />
|-<br />
|[[OpenNebula]]||5.10.5<br />
|-<br />
|[[Ansible]]||2.9.24<br />
|-<br />
|[[Puppet]]||7.9.0<br />
|}<br />
<br />
Состав и версии других пакетов можно посмотреть на сайте [http://packages.altlinux.org/ru/p11/home/ packages.altlinux.org].<br />
<br />
[[Категория:Одиннадцатая платформа]]<br />
<br />
{{Category navigation|title=Одиннадцатая платформа|category=Одиннадцатая платформа}}</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=Branches/p11/TechnicalNotes&diff=71612Branches/p11/TechnicalNotes2023-07-26T12:47:25Z<p>ArsenyMaslennikov: /* Что нового в p11 */</p>
<hr />
<div>{{Stub}}<br />
<br />
[[Категория:Branches]]<br />
<br />
<!-- Не знаю пока, как должно выглядеть оглавление этой страницы, и аналогов в прошлые разы мы не делали. Совсем по-другому строить куст страниц про p11 я тоже не решился. --~~~~ --><br />
<br />
== Что нового в p11 ==<br />
<br />
* Каталоги {{path|/bin}}, {{path|/sbin}}, {{path|/lib*}} [[Usrmerge|объединены]] с аналогами в {{path|/usr}}. Миграция происходит при обновлении пакета {{pkg|filesystem}} на версию из состава p11. При свежей установке p11 {{path|/bin}}, {{path|/sbin}}, {{path|/lib*}} сразу являются симлинками на аналоги в {{path|usr/}}.<br />
** В неопределённом будущем планируется научить инсталлятор формировать recovery-раздел при установке на носитель достаточного объёма. Его создание можно будет отключить по желанию администратора. С его помощью пользователь персоналки или администратор сможет восстановить основную систему.<br />
* (?) Для пользователя <tt>nobody</tt> изменён uid с 99 на значение (65536-2), равное значению [https://docs.kernel.org/admin-guide/sysctl/fs.html#overflowgid-overflowuid overflowuid] в наших ядрах.<br />
* В репозитории разрешены пакеты с символом <tt>~</tt> в версии или релизе. Тильда признана лексикографически старше конца строки, по аналогии с <tt>sort -V</tt> и предназначена для обозначения версий типа release candidate, например, <tt>1.2~rc2</tt>. Это не повлияет на обновление с p9 и p10.<br />
* В репозитории обеспечена поддержка параллельной установки нескольких мажорных ветвей проекта [[LLVM]] одновременно. Утилиты, подобно проекту gcc, устанавливаются с суффиксом, содержащим номер версии (например, <tt>clang-15</tt>). Доступна обёртка с именем без суффикса, которая вызывает команду нужной версии. [[LLVM/Packaging|Подробнее]]<br />
<br />
{{Category navigation|title=Одиннадцатая платформа|category=Одиннадцатая платформа}}</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=Branches/p11/TechnicalNotes&diff=71611Branches/p11/TechnicalNotes2023-07-26T12:26:02Z<p>ArsenyMaslennikov: </p>
<hr />
<div>{{Stub}}<br />
<br />
[[Категория:Branches]]<br />
<br />
<!-- Не знаю пока, как должно выглядеть оглавление этой страницы, и аналогов в прошлые разы мы не делали. Совсем по-другому строить куст страниц про p11 я тоже не решился. --~~~~ --><br />
<br />
== Что нового в p11 ==<br />
<br />
* Каталоги {{path|/bin}}, {{path|/sbin}}, {{path|/lib*}} [[Usrmerge|объединены]] с аналогами в {{path|/usr}}.<br />
* (?) Для пользователя <tt>nobody</tt> изменён uid с 99 на значение (65536-2), равное значению [https://docs.kernel.org/admin-guide/sysctl/fs.html#overflowgid-overflowuid overflowuid] в наших ядрах.<br />
* В репозитории разрешены пакеты с символом <tt>~</tt> в версии или релизе. Тильда признана лексикографически старше конца строки, по аналогии с <tt>sort -V</tt> и предназначена для обозначения версий типа release candidate, например, <tt>1.2~rc2</tt>. Это не повлияет на обновление с p9 и p10.<br />
<br />
{{Category navigation|title=Одиннадцатая платформа|category=Одиннадцатая платформа}}</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=Branches/p11/TechnicalNotes&diff=71517Branches/p11/TechnicalNotes2023-07-25T18:36:28Z<p>ArsenyMaslennikov: Новая страница: «{{Stub}} Категория:Branches <!-- Не знаю пока, как должно выглядеть оглавление этой страницы, и аналогов в прошлые разы мы не делали. Совсем по-другому строить куст страниц про p11 я тоже не решился. --~~~~ --> == Что нового в p11 == * Каталоги {{path|/bin}}, {{path|/sbin}}, {{path|/lib*}} Usr...»</p>
<hr />
<div>{{Stub}}<br />
<br />
[[Категория:Branches]]<br />
<br />
<!-- Не знаю пока, как должно выглядеть оглавление этой страницы, и аналогов в прошлые разы мы не делали. Совсем по-другому строить куст страниц про p11 я тоже не решился. --~~~~ --><br />
<br />
== Что нового в p11 ==<br />
<br />
* Каталоги {{path|/bin}}, {{path|/sbin}}, {{path|/lib*}} [[Usrmerge|объединены]] с аналогами в {{path|/usr}}.<br />
* (?) Для пользователя <tt>nobody</tt> изменён uid с 99 на значение (65536-2), равное значению [https://docs.kernel.org/admin-guide/sysctl/fs.html#overflowgid-overflowuid overflowuid] в наших ядрах.<br />
<br />
{{Category navigation|title=Одиннадцатая платформа|category=Одиннадцатая платформа}}</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=%D0%9E%D0%B4%D0%B8%D0%BD%D0%BD%D0%B0%D0%B4%D1%86%D0%B0%D1%82%D0%B0%D1%8F_%D0%BF%D0%BB%D0%B0%D1%82%D1%84%D0%BE%D1%80%D0%BC%D0%B0&diff=71516Одиннадцатая платформа2023-07-25T18:22:54Z<p>ArsenyMaslennikov: </p>
<hr />
<div>{{Stub}}<br />
<br />
[[Категория:Branches]]<br />
[[Категория:Миграция]]<br />
<br />
Одиннадцатая платформа p11 (), новая стабильная ветка [[branches|репозиториев ALT]], предназначена для разработки, тестирования, распространения, обновления и поддержки комплексных решений всех уровней — от встроенных устройств до серверов предприятий и датацентров, созданная и развиваемая командой ALT ([[ALT Linux Team]]) в рамках проекта [[Sisyphus]]. Одиннадцатая платформа будет поддерживаться [[Компания «Базальт СПО»|ООО «Базальт СПО»]].<br />
<br />
__TOC__<br />
<div id="whatsnew"></div><br />
== Что нового? ==<br />
<br />
На отдельной странице описаны нововведения с точки зрения [[Branches/p11/TechnicalNotes|продвинутых пользователей и администраторов]].<br />
<br />
=== Архитектуры Одиннадцатой платформы ===<br />
<br />
Синхронная сборка p11 производится для пяти основных [[ports|архитектур]]:<br />
<br />
* 64-битных x86_64, aarch64 и ppc64le<br />
* 32-битных i586 и armh (armv7hf)<br />
<!-- armh, возможно, приговорят к выводу из синхронной сборки. --><br />
<br />
Для 32-битной архитектуры mipsel бранч p11 не создаётся.<br />
<br />
Производится также сборка для трёх версий закрытой 64-битной [[эльбрус/архитектура|архитектуры "Эльбрус"]]:<br />
<br />
* e2k (v3, 4С) и e2kv4 (8С/1С+);<br />
* новой e2kv5 (8СВ).<br />
<br />
{{Todo|&nbsp;}}<br />
<br />
== Версии подсистем и пакетов ==<br />
Репозитории одиннадцатой платформы будут обновляться в течение срока поддержки. На момент официального анонса '''p11''' они содержат в том числе:<br />
<br />
{|class="standard"<br />
!ПО<br />
!Версия<br />
|-<br />
|Ядро Linux (std-def)||6.3.8<br />
|-<br />
|Ядро Linux (un-def)||6.3.8<br />
|-<br />
|Ядро Linux ([[OpenVZ|ovz-el7]])||???<br />
|-<br />
|[[systemd]]||254.1<br />
|-<br />
|GNU libc||2.38<br />
|-<br />
|GCC||13.1.1<br />
|-<br />
|LLVM||15.0, 16.0<br />
|-<br />
|Python||3.11.4 и 2.7.18<br />
|-<br />
|Perl||5.34.1<br />
|-<br />
|PHP||8.0.8<br />
|-<br />
|Ruby||2.7.3<br />
|-<br />
|Java||11.0.9.11<br />
|-<br />
|Mono||6.12.0.122<br />
|-<br />
|.NET Core||6.0<br />
|-<br />
|Node||14.17.2<br />
|-<br />
|X.Org Server||21.1.8<br />
|-<br />
|Mesa||21.1.8<br />
|-<br />
|[[GNOME]]||44.3<br />
|-<br />
|[[KDE]]||5.84.0<br />
|-<br />
|[[MATE]]||1.24.1<br />
|-<br />
|[[Xfce]]||4.16.0<br />
|-<br />
|[[Enlightenment]]||0.24.2<br />
|-<br />
|[[Cinnamon]]||5.0.3<br />
|-<br />
|Firefox||115.0, {{pkg|firefox-esr}} ???<br />
|-<br />
|LibreOffice||7.2.0.1, {{pkg|LibreOffice-still}} 7.0.6.2<br />
|-<br />
|[[Samba]]||4.14.6 (с [[SambaDC|samba-dc]])<br />
|-<br />
|Bash||???<br />
|-<br />
|[[BIND]]||9.11.32<br />
|-<br />
|CUPS||2.3.3<br />
|-<br />
|DHCP||4.4.2<br />
|-<br />
|Apache httpd||2.4.48<br />
|-<br />
|nginx||1.24.1<br />
|-<br />
|MariaDB||10.4.20<br />
|-<br />
|PostgreSQL||13.3, 12.6 для [[1C]]<br />
|-<br />
|Postfix||3.6.0<br />
|-<br />
|Dovecot||2.3.14<br />
|-<br />
|[[SOGo]]||5.1.1<br />
|-<br />
|OpenSSL||3.1.1<br />
|-<br />
|GTK+||3.24.30<br />
|-<br />
|Qt||5.15.2<br />
|-<br />
|Tomcat||9.0.45<br />
|-<br />
|[[Docker]]||20.10.7<br />
|-<br />
|[[PVE|Proxmox]]||6.3.3<br />
|-<br />
|[[Kubernetes]]||1.20.8<br />
|-<br />
|[[OpenNebula]]||5.10.5<br />
|-<br />
|[[Ansible]]||2.9.24<br />
|-<br />
|[[Puppet]]||7.9.0<br />
|}<br />
<br />
Состав и версии других пакетов можно посмотреть на сайте [http://packages.altlinux.org/ru/p11/home/ packages.altlinux.org].<br />
<br />
[[Категория:Одиннадцатая платформа]]<br />
<br />
{{Category navigation|title=Одиннадцатая платформа|category=Одиннадцатая платформа}}</div>ArsenyMaslennikovhttps://www.altlinux.org/index.php?title=Usrmerge&diff=71397Usrmerge2023-07-24T22:45:36Z<p>ArsenyMaslennikov: /* Стадия 1 */</p>
<hr />
<div>[[Категория:Sisyphus]]<br />
<br />
= Usrmerge =<br />
'''''Точный план действий сейчас вырабатывается, и его подробности могут измениться.'''''<br />
Статус воплощения отслеживается в {{altbug|46738}}.<br />
<br />
== Введение ==<br />
Исторически<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|/}}, содержащего все эти подкаталоги.<br />
<br />
Позже, с увеличением средних размеров устройств хранения в машинах, сторонники разделения придумали другие обоснования (например, возможность из окружения в {{path|/{bin,sbin,libX,...}/}} починить немонтирующуюся {{path|/usr}}). Но на сегодняшний день непонятно, какой набор утилит и нужных им so/иных файлов стоит признать частью "системы спасения", которая должна быть доступна без {{path|/usr}}, а какой — нет, ибо сами утилиты приобретают универсальный вид и широкие границы применимости. С развитием механизмов initramfs и живых загрузочных/установочных носителей, а также практикой "раздела восстановления" на локальном хранилище машины среди настольных дистрибутивов этот аргумент теряет всякий смысл.<br />
<br />
Чем сохранять бесцельно дублирующие друг друга два класса мест для одних и тех же файлов, лучше оставить один из них, а другой устранить:<br />
* либо переложить {{path|/usr/{bin,sbin,lib,libx32,lib64,libexec,local,share,src,...}}} в корень,<br />
* либо поместить аналоги этих каталогов из {{path|/}} в {{path|/usr}}.<br />
<br />
Из двух вариантов, входящих в рамки FHS<ref>[https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf]</ref>, второй лучше хотя бы тем, что уменьшает количество top-level каталогов, куда упаковывается постоянное содержимое пакетов, до одного. Сейчас среди FHS-совместимых дистрибутивов это типичный подход, на который в том числе потихоньку начинают полагаться апстримы прикладных пакетов.<br />
<br />
== Rationale ==<br />
* Один каталог (пусть с не очень удачным именем {{path|/usr}}) как объект манипуляции и как общий носитель фиксированного содержимого пакетов удобнее россыпи каталогов, полный список которых даже невозможно построить. Появляется даже смысл рассматривать его в виде отдельной точки монтирования, которую можно держать общей на многих машинах под общим управлением.<br />
** Один каталог легче снапшотить, по нему легче гонять {{cmd|find}}, ...<br />
* Упаковка всего пакетного содержимого в {{path|/usr}} открывает дорогу к техническому {{path|/}}, который не находится на устройстве хранения и содержит только пустые каталоги-точки-монтирования.<br />
* Возникает осмысленное разделение между {{path|/usr}}, {{path|/var}} и {{path|/etc}}: первый каталог несёт в себе постоянное содержимое пакетов, не предназначенное к ручной модификации (не через пакетную систему или доставку образа), а другие два уже исторически применяются для переменного хранимого состояния и общесистемных конфигов.<br />
* Сборочным скриптам и прочим интеграционным программным компонентам не нужно будет перебирать каталоги, в которых находится искомая программа.<ref>Вообще-то для этого нужно ещё провести слияние sbin и bin, но оно не несёт срочности и не рассматривается на этой странице.</ref><br />
* Начиная с версии 255, планируемой к выпуску в течение 2023, {{pkg|systemd}} [https://lists.freedesktop.org/archives/systemd-devel/2022-April/047673.html прекратит] поддержку split-usr и unmerged-usr; вот [https://github.com/systemd/systemd/pull/27999/commits/cedcd0bc61913db1e37e19f00d3f97fc72436728 коммит].<br />
** Из кода проекта {{pkg|systemd}}, помимо прочего, исчезнут все упоминания старых каталогов; например, директива <tt>ProtectKernelModules=</tt> больше не будет монтировать заглушку поверх <tt>/lib/modules</tt>, и т. п.<br />
<br />
== Proposed changes ==<br />
Необходимые действия можно разбить на две стадии.<br />
<br />
=== Стадия 1 ===<br />
* На стадии brp завершаться с ошибкой, если обнаружены разные файлы в {{path|/bin/x}} и {{path|/usr/bin/x}}, ...<br />
<br />
1. Определить, что слиянию с аналогами внутри /usr подлежат следующие каталоги:<br />
<pre><br />
/bin<br />
/lib<br />
/lib32<br />
/lib64<br />
/libx32<br />
/sbin<br />
</pre><br />
На каждой машине есть некоторые каталоги из этого списка; они и будут перенесены.<br />
<br />
2. Тем или иным образом научить rpm создавать симлинк вида<br />
<pre><br />
/bin/x -> ../usr/bin/x<br />
</pre><br />
..., если в пакете существует {{path|/usr/bin/x}} и <tt>Provides: /bin/x</tt>. Аналогично для всех каталогов из списка 1. Таким образом, на переходном этапе будет не нужно указывать в <tt>%files</tt> пакетов все эти симлинки, чтобы потом их убирать, и пакеты продолжат удовлетворять зависимостям на такие файлы.<br />
<br />
Важно, чтобы сначала удалялся старый путь, как обычно при установке<br />
пакета, а симлинк возникал после этой фазы.<br />
<br />
2.1) Бекпортировать поддержку в p10.<br />
<br />
3) Подготовить пакет {{pkg|filesystem}} версии 3: поместить в нём файлтриггер,<br />
который проверяет, не состоят ли каталоги из списка 1 целиком из<br />
симлинков внутрь {{path|/usr}}, и превращает такой каталог с симлинками в симлинк<br />
на каталог.<br />
Сценарий файлтриггера должен будет давать предельно ясную информацию и<br />
диагностические сообщения на стандартные потоки. Нужно будет либо<br />
положиться на static coreutils, либо очень осторожно обращаться с<br />
обычными и dynamic linker.<br />
<br />
4) Заменить макросы, использующие старые каталоги (<tt>%_udevrulesdir</tt>,<br />
<tt>%_tmpfilesdir</tt> и другие), и пересобрать с ними пакеты, что-либо<br />
помещающие в эти каталоги.<br />
Приближённое число затрагиваемых бинарных пакетов:<br />
<pre><br />
% grep -E '^/(bin|lib[^/]*|sbin)/[a-z0-9_-]+' contents-index \<br />
| grep -vE '^/lib/(systemd|udev|sysusers.d|modules[^/]*|modprobe.d|security|tmpfiles.d)'<br />
\ # exclude known places<br />
| cut -f2 -d$'\t' | grep -v '^/' # exclude path provides<br />
| sort | uniq | wc -l<br />
528<br />
</pre><br />
Это оценка по x86_64 + noarch. Исходных, конечно, будет меньше.<br />
<br />
При обновлении на эти пакеты будет действовать правило 2, поэтому их<br />
содержимое будет доступно.<br />
<br />
Некоторые пакеты, например, {{pkg|vim-common}}, сейчас упаковывают разные<br />
файловые объекты в {{path|/bin}} и {{path|/usr/bin}}; другие пакеты ставят файлы прямо<br />
в {{path|%buildroot/bin}}. Их потребуется исправить руками. (Справедливости ради,<br />
многие из них и так понадобится обновить)<br />
<br />
=== Стадия 2 ===<br />
Этот пункт вступает в действие на каждой машине индивидуально при<br />
обновлении её пакетов.<br />
Файлтриггер из пункта 3 обнаруживает, что можно ввести симлинки, и<br />
делает это, завершая процесс usrmerge на данной системе.<br />
<br />
Каждая инсталляция перейдёт к ней независимо, как только все пакеты в этой инсталляции будут содержать свои файлы под {{path|/usr}}.<br />
<br />
== Incompatibilities ==<br />
<br />
Если корневая файловая система — каскадная композиция на базе, например, overlayfs, и каталоги {{path|/bin}} и подобные находятся ''не в верхнем'' слое стека — автоматически обновить такую корневую файловую систему на {{pkg|filesystem > 3}} '''не выйдет'''. Придётся либо не обновляться, либо пересобрать контейнер/систему на обновлённой пакетной базе.<br />
<br />
== FAQ ==<br />
<br />
Рекомендуем прочитать другие материалы о преимуществах предлагаемого решения<ref>[https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ TheCaseForTheUsrMerge]</ref><ref>[https://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/ separate-usr-is-broken], примеры, где в ранней системе полагаются на наличие {{path|/usr}}}</ref>.<br />
<br />
'''Q: А что, если {{path|/usr}} на отдельном разделе по каким-то причинам не примонтируется?'''<br />
<br />
A: Тогда система не сможет загрузиться, как и в случае, если {{path|/}} по каким-то причинам не примонтируется.<br />
<br />
'''Q: А раньше можно было, пользуясь программами в {{path|/}}, починить {{path|/usr}}'''<br />
<br />
A: Несколько тезисов:<br />
* В-нулевых, для того, чтобы возникла такая ситуация, систему должны были установить так, чтобы {{path|/usr}} был отдельным от {{path|/}}, т. е. такая разметка преследовала какую-либо цель.<br />
* Во-первых, для этого нужно, чтобы {{path|/}} '''смог''' смонтироваться, а {{path|/usr}} '''не смог'''.<br />
* Во-вторых, всё ещё нет критерия, по которому ту или иную программу и её зависимости можно либо отнести к "системе спасения", либо исключить из неё и сослать в {{path|/usr}}.<br />
* В-третьих, нет ни одного задокументированного случая, где таким образом спасли какую-либо типичную GNU/Linux-систему, включая Альт, есть только [https://www.ecb.torontomu.ca/~elf/hack/recovery.html предание] из 1986 года, касавшееся non-Linux тех времён на компьютере тех времён. Рецептов такого восстановления, отчуждаемых от компетенций разработчиков ALT и умелых сисадминов, нет тем более. Следовательно, можно заключить, что в общем случае цитируемая возможность восстановить {{path|/usr}} из {{path|/}} — призрачна.<br />
* Несмотря на всё это, нет ничего плохого в том, чтобы рецепт такого спасения (при помощи операционной избыточности инсталляции альта) администратору ''предложить'', но это должен быть явный механизм с минимумом издержек для остальной структуры системы. Есть множество вариантов это реализовать с разными преимуществами и минусами в разных установках; все они out of scope for this document.<br />
<br />
== User-visible impact ==<br />
Меньше каталогов верхнего уровня в корне, кроме симлинков.<br />
<br />
== Appendix ==</div>ArsenyMaslennikov