ALT Linux Team development discussions
 help / color / mirror / Atom feed
* [devel] I: usrmerge
@ 2024-02-02 21:38 Arseny Maslennikov
  2024-02-03  7:46 ` Anton Farygin
  2024-03-16 13:24 ` Arseny Maslennikov
  0 siblings, 2 replies; 34+ messages in thread
From: Arseny Maslennikov @ 2024-02-02 21:38 UTC (permalink / raw)
  To: devel

[-- Attachment #1: Type: text/plain, Size: 8552 bytes --]

Предыдущее обсуждение — в треде:
https://lore.altlinux.org/devel/ZKQaFPEN0qnNWGnz@cello/

Приблизительно 1.5 месяца назад наконец-то появилась возможность
продолжить подготовку. Так как в этой рассылке долго не было
новостей по поводу usrmerge, наверное, уже стоит более подробно
рассказать, каким образом мы собираемся получить пакеты в
Sisyphus, совместимые с новой иерархией корня, и обеспечить
миграцию уже установленных систем.

=== Сначала о пакетах ===
Во-первых, не хотелось бы обновлять сотню пакетов в одной
транзакции с пакетом filesystem, содержащим вместо /bin, /sbin,
... симлинки. Чтобы этого избежать, надо добиться, чтобы пакеты,
кладущие что-либо в эти каталоги (вне %_prefix),
устанавливались и на merged, и на unmerged, и на split[1].
Для этого планируется ввести brp-модуль, который при сборке
пакета, если в %buildroot лежит что-то в соотв. каталогах вне
префикса, создаст копию этого файла в аналогичном месте под
префиксом.
Можно было бы вместо копии делать ссылку, но оказалось, что нет:
* (упакованные в cpio) симлинк поверх файла или файл поверх симлинка нельзя
  установить на merged-usr, т. е. поверх друг друга;
* (упакованные в cpio) хардлинки нельзя установить на
  split-usr-иерархию, потому что они придутся на разные ФС, и
  rpm не сможет их расщепить (изготовить одинаковые inode).
Это позволило снизить количество пакетов с файлами в /bin и
/sbin, для которых потребуются ручные изменения, с 90 до ~20.

[1] https://www.altlinux.org/Usrmerge#%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9

Осталось ещё выяснить, требуется ли менять пакеты с разделяемыми
библиотеками и сколько таких пакетов. Поначалу у меня было
впечатление, что из-за проверки duplicate provides на сборочнице
у нас просто нет разных пар файлов вида /lib64/x и /usr/lib64/x,
но оно оказалось ошибочным. В основном это библиотеки или
симлинки на них без .x.x.x-суффикса; часто такие файлы попали
под /%_lib в составе -devel-пакета по ошибке.

Мы ожидаем, что после появления rpm-build с новым brp-модулем в
репозитории немногочисленные исправленные пакеты будут собраны в
Sisyphus в своих индивидуальных заданиях (транзакциях), не
создавая на сборочнице заторов на CI-проверках каждого
подзадания.

Помимо прочего, это означает, что мы не будем убирать из спеков
костыли для переноса файлов в %buildroot из %_bindir в /bin и т.
п., потому что этот код всё ещё не будет мёртвым.

Отключить логику brp-модуля и убрать костыли из скриптов в
спеках станет можно после того, как в среднесрочном будущем мы
прекратим поддержку апгрейда с unmerged-usr-систем (видимо,
через несколько лет). Как минимум стоит поддерживать индуктивное
обновление с pN на pN+1 по мере выхода этих репозиториев.

=== Теперь о миграции ===

После того, как все (допускаю, что за ничтожными исключениями)
пересобираемые пакеты в Sisyphus станут устанавливаться и на
старые иерархии, и на новые, настанет время собрать в
репозиторий пакет filesystem (версией > 3) уже с симлинками
вместо каталогов.

Это самая сложная часть процесса:
* пакеты должны будут пересобираться в merged-иерархии, сейчас
  мы это проверяем вручную;
* чтобы он мог установиться на уже заполненный корень,
  например, в установленную unmerged-систему, симлинки уже
  должны быть расставлены на месте каким-то иным инструментом
  перед тем, как rpm распакует пакет.

Мне известно два метода решения этой задачи: один реализуем точно,
а другой умозрительно.
* Переносить файлы и создать симлинки специальным инструментом[2]
  прямо перед распаковкой пакета filesystem: либо в %pre этого
  пакета, либо в %pretrans. В качестве дополнительной меры
  предохранения попробовать добиться, чтобы filesystem
  в rpm-транзакции стоял позже, чем другие затронутые пакеты.
* (умозрительный способ) Добиться того, чтобы на системах с
  unmerged-иерархией filesystem > 3 не попадал в rpm-транзакцию, а
  специальный инструмент запускать в filetrigger после
  транзакции, когда выяснится (каков критерий?), что все пакеты
  обновлены до версий, подготовленных как описано в предыдущей
  секции, и конфликтов при копировании больше не будет.
Инструмент для слияния сводится к cp -Tal, мерам обеспечения
атомичности замен каталогов на симлинки (файлы по своим путям
должны быть доступны в любой момент времени), вариантам обхода
многочисленных особых случаев в старых пакетах, с которыми сама
команда cp -Tal не справится. При втором методе (в posttrans)
он, в теории, может быть устроен проще, и проще доказать, что
перенос не может сломаться ни при каком состоянии релевантного
поддерева ФС.

[2] https://packages.altlinux.org/en/sisyphus/srpms/usrmerge/

Я пока что предполагаю, что нам придётся пользоваться первым
методом, но не исключаю, что удастся придумать реализацию
второго.

Вот такие пока новости. :)
Страницу на вики я собираюсь обновлять по мере превращения планируемых
действий в уже совершённые, т. е. лучше, чтобы она отражала уже принятые
решения и факты.
Предлагаю обсуждать процесс тут, если есть что обсуждать.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] I: usrmerge
  2024-02-02 21:38 [devel] I: usrmerge Arseny Maslennikov
@ 2024-02-03  7:46 ` Anton Farygin
  2024-02-03  9:46   ` Arseny Maslennikov
                     ` (2 more replies)
  2024-03-16 13:24 ` Arseny Maslennikov
  1 sibling, 3 replies; 34+ messages in thread
From: Anton Farygin @ 2024-02-03  7:46 UTC (permalink / raw)
  To: devel

On 03.02.2024 00:38, Arseny Maslennikov wrote:
> Предыдущее обсуждение — в треде:
> https://lore.altlinux.org/devel/ZKQaFPEN0qnNWGnz@cello/


У меня основной вопрос - сломаю ли я что-то, если уже сейчас начну в 
своих пакетах переделывать на %_prefix (кое-где я так уже сделал и этого 
вроде никто не заметил( ?

Ну и второй - не пора ли плавно добавить в make-initrd поддержку нового 
расположения для /lib/firmware и /lib/modules, плавно на уровне пакетов 
сделав нужную миграцию, поддерживающую обновления ?

Почему-то мне кажется что чем больше пакетов переедут самостоятельно, 
тем меньше сложность вопросов, которые нужно будет решать в rpm и 
сборочной системе.





^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] I: usrmerge
  2024-02-03  7:46 ` Anton Farygin
@ 2024-02-03  9:46   ` Arseny Maslennikov
  2024-02-03 10:05     ` Anton Farygin
  2024-02-03 10:31   ` Arseny Maslennikov
  2024-02-03 14:41   ` [devel] I: usrmerge Alexey Gladkov
  2 siblings, 1 reply; 34+ messages in thread
From: Arseny Maslennikov @ 2024-02-03  9:46 UTC (permalink / raw)
  To: ALT Linux Team development discussions

[-- Attachment #1: Type: text/plain, Size: 2905 bytes --]

On Sat, Feb 03, 2024 at 10:46:42AM +0300, Anton Farygin wrote:
> On 03.02.2024 00:38, Arseny Maslennikov wrote:
> > Предыдущее обсуждение — в треде:
> > https://lore.altlinux.org/devel/ZKQaFPEN0qnNWGnz@cello/
> 
> 
> У меня основной вопрос - сломаю ли я что-то, если уже сейчас начну в своих
> пакетах переделывать на %_prefix

Нет, если сделаете всё правильно. :)

Надо обеспечить, чтобы пакет ставился и на merged-, и на unmerged-. Если
мейнтейнеры хотели бы сами, руками, поправить соотв. образом свои пакеты,
ничего страшного в этом не будет. Для этого надо, как описано в предыдущем
письме, создавать в %buildroot копии и указать их в %files (где они уже
указаны, скорее всего).

> (кое-где я так уже сделал и этого вроде
> никто не заметил( ?

btrfs-progs уже сегодня не устанавливается на split-usr-конфигурацию,
да, потому что там жёсткие ссылки. Впрочем, багу по этому поводу до сей
поры действительно никто ещё не создал! =)

Но я тем не менее убеждён, что не стоит считать, что split-usr ни у кого
нет; иначе после начала массового перехода пакетов появятся и жалобы —
громкие и агрессивные, с угрозами жизни и здоровью. Очень вероятно, что
те, кто ставил так систему, просто не любят btrfs.

> Ну и второй - не пора ли плавно добавить в make-initrd поддержку нового
> расположения для /lib/firmware и /lib/modules, плавно на уровне пакетов
> сделав нужную миграцию, поддерживающую обновления ?

В merged-usr иерархии будет симлинк /lib -> usr/lib.
Нужные файлы будут доступны и по новому, и по старому расположению; не
вижу пока смысла что-то здесь предпринимать, как и явно упаковывать
/lib/firmware и /lib/modules в firmware-linux и ядрах под префикс.
Если изменить там путь, то такие пакеты перестанут поддерживать
unmerged-usr совсем. Это стоит делать не сразу.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] I: usrmerge
  2024-02-03  9:46   ` Arseny Maslennikov
@ 2024-02-03 10:05     ` Anton Farygin
  2024-02-03 10:21       ` Антон Мидюков
                         ` (2 more replies)
  0 siblings, 3 replies; 34+ messages in thread
From: Anton Farygin @ 2024-02-03 10:05 UTC (permalink / raw)
  To: devel

On 03.02.2024 12:46, Arseny Maslennikov wrote:
> On Sat, Feb 03, 2024 at 10:46:42AM +0300, Anton Farygin wrote:
>> On 03.02.2024 00:38, Arseny Maslennikov wrote:
>>> Предыдущее обсуждение — в треде:
>>> https://lore.altlinux.org/devel/ZKQaFPEN0qnNWGnz@cello/
>>
>> У меня основной вопрос - сломаю ли я что-то, если уже сейчас начну в своих
>> пакетах переделывать на %_prefix
> Нет, если сделаете всё правильно. :)
>
> Надо обеспечить, чтобы пакет ставился и на merged-, и на unmerged-. Если
> мейнтейнеры хотели бы сами, руками, поправить соотв. образом свои пакеты,
> ничего страшного в этом не будет. Для этого надо, как описано в предыдущем
> письме, создавать в %buildroot копии и указать их в %files (где они уже
> указаны, скорее всего).

Я не могу проверить на merged, т.к. у меня такой системы нет.

Вообще я надеюсь что когда-то я скажу dist-upgrade и всё произойдёт само 
в рамках обновления.

>
>> (кое-где я так уже сделал и этого вроде
>> никто не заметил( ?
> btrfs-progs уже сегодня не устанавливается на split-usr-конфигурацию,
> да, потому что там жёсткие ссылки. Впрочем, багу по этому поводу до сей
> поры действительно никто ещё не создал! =)
От жёстких ссылок как раз легко избавиться, они были сделаны в рамках 
"совместимости".
>
> Но я тем не менее убеждён, что не стоит считать, что split-usr ни у кого
> нет; иначе после начала массового перехода пакетов появятся и жалобы —
> громкие и агрессивные, с угрозами жизни и здоровью. Очень вероятно, что
> те, кто ставил так систему, просто не любят btrfs.

Или людей с отдельно-смонтированным /usr уже не осталось.

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

>
>> Ну и второй - не пора ли плавно добавить в make-initrd поддержку нового
>> расположения для /lib/firmware и /lib/modules, плавно на уровне пакетов
>> сделав нужную миграцию, поддерживающую обновления ?
> В merged-usr иерархии будет симлинк /lib -> usr/lib.
> Нужные файлы будут доступны и по новому, и по старому расположению; не
> вижу пока смысла что-то здесь предпринимать, как и явно упаковывать
> /lib/firmware и /lib/modules в firmware-linux и ядрах под префикс.
> Если изменить там путь, то такие пакеты перестанут поддерживать
> unmerged-usr совсем. Это стоит делать не сразу.

Почему же перестанут ? просто все конфигурации одновременно обновятся и 
уйдут на префикс.

Единственное что перестанет работать - так это те системы, которые были 
установлены с отдельным от корня /usr

Но об этом как раз надо сделать анонс и чем быстрее тем лучше.




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] I: usrmerge
  2024-02-03 10:05     ` Anton Farygin
@ 2024-02-03 10:21       ` Антон Мидюков
  2024-02-03 10:57         ` Arseny Maslennikov
  2024-02-03 11:12       ` [devel] possible incompatibilities (was: I: usrmerge) Arseny Maslennikov
  2024-02-16  7:04       ` [devel] I: usrmerge Sergey Afonin
  2 siblings, 1 reply; 34+ messages in thread
From: Антон Мидюков @ 2024-02-03 10:21 UTC (permalink / raw)
  To: devel

03.02.2024 17:05, Anton Farygin пишет:
> On 03.02.2024 12:46, Arseny Maslennikov wrote:
>> On Sat, Feb 03, 2024 at 10:46:42AM +0300, Anton Farygin wrote:

>>> Ну и второй - не пора ли плавно добавить в make-initrd поддержку нового
>>> расположения для /lib/firmware и /lib/modules, плавно на уровне пакетов
>>> сделав нужную миграцию, поддерживающую обновления ?
>> В merged-usr иерархии будет симлинк /lib -> usr/lib.
>> Нужные файлы будут доступны и по новому, и по старому расположению; не
>> вижу пока смысла что-то здесь предпринимать, как и явно упаковывать
>> /lib/firmware и /lib/modules в firmware-linux и ядрах под префикс.
>> Если изменить там путь, то такие пакеты перестанут поддерживать
>> unmerged-usr совсем. Это стоит делать не сразу.
> 
> Почему же перестанут ? просто все конфигурации одновременно обновятся и уйдут на префикс.
> 
> Единственное что перестанет работать - так это те системы, которые были установлены с отдельным от корня /usr

Так если initrd умеет монтировать /usr, то не должно быть разницы с системами, у которых нет отдельного /usr?
Или всё-таки нет?

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] I: usrmerge
  2024-02-03  7:46 ` Anton Farygin
  2024-02-03  9:46   ` Arseny Maslennikov
@ 2024-02-03 10:31   ` Arseny Maslennikov
  2024-02-05  5:48     ` Anton Farygin
  2024-02-07 15:57     ` [devel] usrmerge: future conflicts in /lib* Arseny Maslennikov
  2024-02-03 14:41   ` [devel] I: usrmerge Alexey Gladkov
  2 siblings, 2 replies; 34+ messages in thread
From: Arseny Maslennikov @ 2024-02-03 10:31 UTC (permalink / raw)
  To: ALT Linux Team development discussions

[-- Attachment #1: Type: text/plain, Size: 2277 bytes --]

On Sat, Feb 03, 2024 at 10:46:42AM +0300, Anton Farygin wrote:
> On 03.02.2024 00:38, Arseny Maslennikov wrote:
> > Предыдущее обсуждение — в треде:
> > https://lore.altlinux.org/devel/ZKQaFPEN0qnNWGnz@cello/
> 
> Почему-то мне кажется что чем больше пакетов переедут самостоятельно, тем
> меньше сложность вопросов, которые нужно будет решать в rpm и сборочной
> системе.

Связь тут неравномерная: ряд пакетов уже и так собираются и ставятся,
будучи собраны с прототипом brp-модуля. Но некоторые отдельные пакеты,
может быть, и стоит поправить заранее.

Например, есть библиотеки, где под /lib64 зачем-то лежат
devel-симлинки; или в этом каталоге лежит сама библиотека, но клиентов в
/bin и /sbin у неё нет.
Сейчас brp-модуль игнорирует /lib и /%_lib; если
мейнтейнеры исправят свои такие пакеты, это поможет.


Или, например, есть такой пакет pcc, который упаковывает файл /usr/lib/cpp.
Путь /lib/cpp встречается в configure-скриптах из-под достаточно старых
версий autoconf; скрипт начинает его проверять, если недоступны или
работают не так "$CC -E" и "$CC -E -traditional-cpp".
В debian этот путь вообще отсутствует.
Я бы просто перед запуском такого configure-скрипта делал так:
    sed -i 's!"/lib/cpp"!"$CC -E"!' ./configure
А вот /usr/lib/cpp сам собой не используется вообще никем.

На merged-usr иерархии пакет pcc со своим файлом /usr/lib/cpp начнёт
иметь мисконфликт с gcc-common, чей симлинк /lib/cpp тоже попадёт в
/usr/lib.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] I: usrmerge
  2024-02-03 10:21       ` Антон Мидюков
@ 2024-02-03 10:57         ` Arseny Maslennikov
  2024-02-03 14:44           ` Alexey Gladkov
  0 siblings, 1 reply; 34+ messages in thread
From: Arseny Maslennikov @ 2024-02-03 10:57 UTC (permalink / raw)
  To: ALT Linux Team development discussions

[-- Attachment #1: Type: text/plain, Size: 3565 bytes --]

On Sat, Feb 03, 2024 at 05:21:35PM +0700, Антон Мидюков wrote:
> 03.02.2024 17:05, Anton Farygin пишет:
> > On 03.02.2024 12:46, Arseny Maslennikov wrote:
> >> On Sat, Feb 03, 2024 at 10:46:42AM +0300, Anton Farygin wrote:
> 
> >>> Ну и второй - не пора ли плавно добавить в make-initrd поддержку нового
> >>> расположения для /lib/firmware и /lib/modules, плавно на уровне пакетов
> >>> сделав нужную миграцию, поддерживающую обновления ?
> >> В merged-usr иерархии будет симлинк /lib -> usr/lib.
> >> Нужные файлы будут доступны и по новому, и по старому расположению; не
> >> вижу пока смысла что-то здесь предпринимать, как и явно упаковывать
> >> /lib/firmware и /lib/modules в firmware-linux и ядрах под префикс.
> >> Если изменить там путь, то такие пакеты перестанут поддерживать
> >> unmerged-usr совсем. Это стоит делать не сразу.
> > 
> > Почему же перестанут ? просто все конфигурации одновременно обновятся и уйдут на префикс.

Синхронизировать апгрейд всех пакетов, требующих его, апгрейд
make-initrd (и перегенерацию им initramfs) и установку filesystem 3
во всех конфигурациях очень сложно. Полагать, что все конфигурации
смогут одновременно обновиться, наивно.

Ну и, как я понимаю, проект make-initrd ставит одной из целей поддержку
не только альта.

> > 
> > Единственное что перестанет работать - так это те системы, которые были установлены с отдельным от корня /usr
> 
> Так если initrd умеет монтировать /usr, то не должно быть разницы с системами, у которых нет отдельного /usr?
> Или всё-таки нет?

Насколько я понимаю, не должно.

Более того, merged-usr-система, в которой /usr отдельный от корня, тоже
возможна, но она не будет называться split-usr. В задачу инитрд в этом
окружении точно так же будет входить монтирование /usr (может быть, из
сквоша или по сети), а файловая система, монтируемая на "/", будет
содержать /etc, каталоги-симлинки /bin /sbin /lib*, а также
каталоги-заглушки
(/sys /proc /dev /run /var /srv /tmp ...), поверх которых монтируются
соотв. разделы и API FS (или не монтируются и не заглушки, а просто там
файлы лежат под этими каталогами на носителе "/").

Это имеет смысл, например, для бездисковых иерархий, загружаемых по
сети, и систем на RO-образах.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* [devel] possible incompatibilities (was:  I: usrmerge)
  2024-02-03 10:05     ` Anton Farygin
  2024-02-03 10:21       ` Антон Мидюков
@ 2024-02-03 11:12       ` Arseny Maslennikov
  2024-02-03 15:58         ` Aleksey Novodvorsky
  2024-02-04  7:46         ` [devel] possible incompatibilities Антон Мидюков
  2024-02-16  7:04       ` [devel] I: usrmerge Sergey Afonin
  2 siblings, 2 replies; 34+ messages in thread
From: Arseny Maslennikov @ 2024-02-03 11:12 UTC (permalink / raw)
  To: ALT Linux Team development discussions

[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]

On Sat, Feb 03, 2024 at 01:05:47PM +0300, Anton Farygin wrote:
> Единственное что перестанет работать - так это те системы, которые были
> установлены с отдельным от корня /usr
> 
> Но об этом как раз надо сделать анонс и чем быстрее тем лучше.

Раз уж мы заговорили про анонсы:

В топикстартере я описал две стратегии переноса уже развёрнутых
инсталляций: усл. "pre" и "posttrans".
Так вот если мы пойдём по пути "pre" (пока всё к этому), то будем
рекомендовать при апгрейде, например, с p10 сначала обновляться на
Sisyphus от конкретной даты (после того, как релев. пакеты с файлами вне
префикса исправлены или пересобраны, но ещё с filesystem < 3), а потом
на p11 или актуальный Sisyphus. Так меньше шанс нарваться на редкие,
плохо тестируемые ситуации.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] I: usrmerge
  2024-02-03  7:46 ` Anton Farygin
  2024-02-03  9:46   ` Arseny Maslennikov
  2024-02-03 10:31   ` Arseny Maslennikov
@ 2024-02-03 14:41   ` Alexey Gladkov
  2024-02-05  5:47     ` Anton Farygin
  2 siblings, 1 reply; 34+ messages in thread
From: Alexey Gladkov @ 2024-02-03 14:41 UTC (permalink / raw)
  To: ALT Linux Team development discussions

On Sat, Feb 03, 2024 at 10:46:42AM +0300, Anton Farygin wrote:
> On 03.02.2024 00:38, Arseny Maslennikov wrote:
> > Предыдущее обсуждение — в треде:
> > https://lore.altlinux.org/devel/ZKQaFPEN0qnNWGnz@cello/
> 
> Ну и второй - не пора ли плавно добавить в make-initrd поддержку нового 
> расположения для /lib/firmware и /lib/modules, плавно на уровне пакетов 
> сделав нужную миграцию, поддерживающую обновления ?

make-initrd уже умеет загружать мигрировавшие на usrmerge системы. Он
также умеет определять, что /usr отдельный mountpoint и монировать и его.
Это нужно для схем usrmerge + separate-usr, если у кого-нибудь такие
остались.

-- 
Rgrds, legion



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] I: usrmerge
  2024-02-03 10:57         ` Arseny Maslennikov
@ 2024-02-03 14:44           ` Alexey Gladkov
  0 siblings, 0 replies; 34+ messages in thread
From: Alexey Gladkov @ 2024-02-03 14:44 UTC (permalink / raw)
  To: ALT Linux Team development discussions

On Sat, Feb 03, 2024 at 01:57:57PM +0300, Arseny Maslennikov wrote:
> On Sat, Feb 03, 2024 at 05:21:35PM +0700, Антон Мидюков wrote:
> > 03.02.2024 17:05, Anton Farygin пишет:
> > > On 03.02.2024 12:46, Arseny Maslennikov wrote:
> > >> On Sat, Feb 03, 2024 at 10:46:42AM +0300, Anton Farygin wrote:
> > 
> > >>> Ну и второй - не пора ли плавно добавить в make-initrd поддержку нового
> > >>> расположения для /lib/firmware и /lib/modules, плавно на уровне пакетов
> > >>> сделав нужную миграцию, поддерживающую обновления ?
> > >> В merged-usr иерархии будет симлинк /lib -> usr/lib.
> > >> Нужные файлы будут доступны и по новому, и по старому расположению; не
> > >> вижу пока смысла что-то здесь предпринимать, как и явно упаковывать
> > >> /lib/firmware и /lib/modules в firmware-linux и ядрах под префикс.
> > >> Если изменить там путь, то такие пакеты перестанут поддерживать
> > >> unmerged-usr совсем. Это стоит делать не сразу.
> > > 
> > > Почему же перестанут ? просто все конфигурации одновременно обновятся и уйдут на префикс.
> 
> Синхронизировать апгрейд всех пакетов, требующих его, апгрейд
> make-initrd (и перегенерацию им initramfs) и установку filesystem 3
> во всех конфигурациях очень сложно. Полагать, что все конфигурации
> смогут одновременно обновиться, наивно.
> 
> Ну и, как я понимаю, проект make-initrd ставит одной из целей поддержку
> не только альта.

Вы правильно понимаете. Сейчас у меня есть end-to-end тесты загрузки alt,
fedora, ubuntu и плюс я тестирую загрузку gentoo.

-- 
Rgrds, legion



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] possible incompatibilities (was: I: usrmerge)
  2024-02-03 11:12       ` [devel] possible incompatibilities (was: I: usrmerge) Arseny Maslennikov
@ 2024-02-03 15:58         ` Aleksey Novodvorsky
  2024-02-04  7:46         ` [devel] possible incompatibilities Антон Мидюков
  1 sibling, 0 replies; 34+ messages in thread
From: Aleksey Novodvorsky @ 2024-02-03 15:58 UTC (permalink / raw)
  To: ALT Linux Team development discussions

сб, 3 февр. 2024 г. в 14:13, Arseny Maslennikov <arseny@altlinux.org>:
>
> On Sat, Feb 03, 2024 at 01:05:47PM +0300, Anton Farygin wrote:
> > Единственное что перестанет работать - так это те системы, которые были
> > установлены с отдельным от корня /usr
> >
> > Но об этом как раз надо сделать анонс и чем быстрее тем лучше.
>
> Раз уж мы заговорили про анонсы:
>
> В топикстартере я описал две стратегии переноса уже развёрнутых
> инсталляций: усл. "pre" и "posttrans".
> Так вот если мы пойдём по пути "pre" (пока всё к этому), то будем
> рекомендовать при апгрейде, например, с p10 сначала обновляться на
> Sisyphus от конкретной даты (после того, как релев. пакеты с файлами вне
> префикса исправлены или пересобраны, но ещё с filesystem < 3), а потом
> на p11 или актуальный Sisyphus.

Этот способ вряд ли годен, так как p10 не заморожен и еще год будет
сопровождаться. Версии некоторых пакетов в нем обгонят срез "Sisyphus
от конкретной даты".

Rgrds, Алексей

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] possible incompatibilities
  2024-02-03 11:12       ` [devel] possible incompatibilities (was: I: usrmerge) Arseny Maslennikov
  2024-02-03 15:58         ` Aleksey Novodvorsky
@ 2024-02-04  7:46         ` Антон Мидюков
  2024-02-04 10:30           ` Arseny Maslennikov
  1 sibling, 1 reply; 34+ messages in thread
From: Антон Мидюков @ 2024-02-04  7:46 UTC (permalink / raw)
  To: devel

03.02.2024 18:12, Arseny Maslennikov пишет:
> On Sat, Feb 03, 2024 at 01:05:47PM +0300, Anton Farygin wrote:
>> Единственное что перестанет работать - так это те системы, которые были
>> установлены с отдельным от корня /usr
>>
>> Но об этом как раз надо сделать анонс и чем быстрее тем лучше.
> 
> Раз уж мы заговорили про анонсы:
> 
> В топикстартере я описал две стратегии переноса уже развёрнутых
> инсталляций: усл. "pre" и "posttrans".
> Так вот если мы пойдём по пути "pre" (пока всё к этому), то будем
> рекомендовать при апгрейде, например, с p10 сначала обновляться на
> Sisyphus от конкретной даты (после того, как релев. пакеты с файлами вне
> префикса исправлены или пересобраны, но ещё с filesystem < 3), а потом
> на p11 или актуальный Sisyphus. Так меньше шанс нарваться на редкие,
> плохо тестируемые ситуации.
> 

А эта рекомендация для систем с отдельным /usr или вообще всем?
Почему самостоятельный переезд пакетов в /usr/ может сломать в будущем переезд на usr-merge?
Чем больше пакетов самостоятельно переедет, тем обновление должно становиться более гладким.
Почему нет?

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] possible incompatibilities
  2024-02-04  7:46         ` [devel] possible incompatibilities Антон Мидюков
@ 2024-02-04 10:30           ` Arseny Maslennikov
  2024-02-04 10:45             ` Антон Мидюков
  2024-02-05  4:42             ` Ildar Mulyukov
  0 siblings, 2 replies; 34+ messages in thread
From: Arseny Maslennikov @ 2024-02-04 10:30 UTC (permalink / raw)
  To: ALT Linux Team development discussions

[-- Attachment #1: Type: text/plain, Size: 3388 bytes --]

On Sun, Feb 04, 2024 at 02:46:44PM +0700, Антон Мидюков wrote:
> 03.02.2024 18:12, Arseny Maslennikov пишет:
> > On Sat, Feb 03, 2024 at 01:05:47PM +0300, Anton Farygin wrote:
> >> Единственное что перестанет работать - так это те системы, которые были
> >> установлены с отдельным от корня /usr
> >>
> >> Но об этом как раз надо сделать анонс и чем быстрее тем лучше.
> > 
> > Раз уж мы заговорили про анонсы:
> > 
> > В топикстартере я описал две стратегии переноса уже развёрнутых
> > инсталляций: усл. "pre" и "posttrans".
> > Так вот если мы пойдём по пути "pre" (пока всё к этому), то будем
> > рекомендовать при апгрейде, например, с p10 сначала обновляться на
> > Sisyphus от конкретной даты (после того, как релев. пакеты с файлами вне
> > префикса исправлены или пересобраны, но ещё с filesystem < 3), а потом
> > на p11 или актуальный Sisyphus. Так меньше шанс нарваться на редкие,
> > плохо тестируемые ситуации.

> А эта рекомендация для систем с отдельным /usr или вообще всем?

Для всех. Либо так, либо мы найдём способ делать это в файлтриггере
после обновления пакетов.

> Почему самостоятельный переезд пакетов в /usr/ может сломать в будущем переезд на usr-merge?

Тут надо прояснить смыслы слов.

Я так понял, что переезд — это наивный перенос; взять и упаковать в
другое место, из старого убрать. Такой наивный перенос файлов ломает не
будущее, а обновление с прошлого.

Вот гипотетический пример: если в соотв. пакетах, например, coreutils
или util-linux, просто взять и убрать все файлы вне префикса,
перенеся, например, /sbin/mount в /usr/sbin/mount, то:
- на системах со split-usr при загрузке до появления /usr файл
  /bin/mount будет отсутствовать;
- такой пакет перестанет удовлетворять Requires: /sbin/mount.
Или, если речь идёт о sh и awk каких-нибудь, они часто указаны в
сценариях в качестве интерпретаторов: "#!/bin/awk". Файл по этому пути
должен быть.

А если я неправильно понял слово "переезд" и оно означает приведение
пакета в вид, совместимый и с m-usr, и c unm-usr, тогда нет, не сломает.
Я нигде не писал, что сломает.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] possible incompatibilities
  2024-02-04 10:30           ` Arseny Maslennikov
@ 2024-02-04 10:45             ` Антон Мидюков
  2024-02-04 12:20               ` Arseny Maslennikov
  2024-02-05  4:42             ` Ildar Mulyukov
  1 sibling, 1 reply; 34+ messages in thread
From: Антон Мидюков @ 2024-02-04 10:45 UTC (permalink / raw)
  To: devel

04.02.2024 17:30, Arseny Maslennikov пишет:
> On Sun, Feb 04, 2024 at 02:46:44PM +0700, Антон Мидюков wrote:
>> 03.02.2024 18:12, Arseny Maslennikov пишет:
>>> On Sat, Feb 03, 2024 at 01:05:47PM +0300, Anton Farygin wrote:
>>>> Единственное что перестанет работать - так это те системы, которые были
>>>> установлены с отдельным от корня /usr
>>>>
>>>> Но об этом как раз надо сделать анонс и чем быстрее тем лучше.
>>>
>>> Раз уж мы заговорили про анонсы:
>>>
>>> В топикстартере я описал две стратегии переноса уже развёрнутых
>>> инсталляций: усл. "pre" и "posttrans".
>>> Так вот если мы пойдём по пути "pre" (пока всё к этому), то будем
>>> рекомендовать при апгрейде, например, с p10 сначала обновляться на
>>> Sisyphus от конкретной даты (после того, как релев. пакеты с файлами вне
>>> префикса исправлены или пересобраны, но ещё с filesystem < 3), а потом
>>> на p11 или актуальный Sisyphus. Так меньше шанс нарваться на редкие,
>>> плохо тестируемые ситуации.
> 
>> А эта рекомендация для систем с отдельным /usr или вообще всем?
> 
> Для всех. Либо так, либо мы найдём способ делать это в файлтриггере
> после обновления пакетов.
> 
>> Почему самостоятельный переезд пакетов в /usr/ может сломать в будущем переезд на usr-merge?
> 
> Тут надо прояснить смыслы слов.
> 
> Я так понял, что переезд — это наивный перенос; взять и упаковать в
> другое место, из старого убрать. Такой наивный перенос файлов ломает не
> будущее, а обновление с прошлого.

Да, я про такой перенос. Но перенос уже после того, как filesystem в репозитории обновлён.
Разумеется, я не про то, чтобы собирать в p10 такие пакеты. А только в p11 и Сизиф.

> 
> Вот гипотетический пример: если в соотв. пакетах, например, coreutils
> или util-linux, просто взять и убрать все файлы вне префикса,
> перенеся, например, /sbin/mount в /usr/sbin/mount, то:
> - на системах со split-usr при загрузке до появления /usr файл
>   /bin/mount будет отсутствовать;

При обновления /usr уже примонтирован.

> - такой пакет перестанет удовлетворять Requires: /sbin/mount.

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

> Или, если речь идёт о sh и awk каких-нибудь, они часто указаны в
> сценариях в качестве интерпретаторов: "#!/bin/awk". Файл по этому пути
> должен быть.

Так после обновления всё уже будет.

Я не понимаю, почему мы не можем сразу же после обновления filesystem начать перенос в спеках в /usr по мере обновления пакетов, которые не планируется собирать в p10.
Почему мы должны ждать p12?

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] possible incompatibilities
  2024-02-04 10:45             ` Антон Мидюков
@ 2024-02-04 12:20               ` Arseny Maslennikov
  2024-02-04 13:28                 ` Антон Мидюков
  0 siblings, 1 reply; 34+ messages in thread
From: Arseny Maslennikov @ 2024-02-04 12:20 UTC (permalink / raw)
  To: ALT Linux Team development discussions

[-- Attachment #1: Type: text/plain, Size: 6119 bytes --]

On Sun, Feb 04, 2024 at 05:45:23PM +0700, Антон Мидюков wrote:
> 04.02.2024 17:30, Arseny Maslennikov пишет:
> > On Sun, Feb 04, 2024 at 02:46:44PM +0700, Антон Мидюков wrote:
> >> Почему самостоятельный переезд пакетов в /usr/ может сломать в будущем переезд на usr-merge?
> > 
> > Тут надо прояснить смыслы слов.
> > 
> > Я так понял, что переезд — это наивный перенос; взять и упаковать в
> > другое место, из старого убрать. Такой наивный перенос файлов ломает не
> > будущее, а обновление с прошлого.
> 
> Да, я про такой перенос. Но перенос уже после того, как filesystem в репозитории обновлён.
> Разумеется, я не про то, чтобы собирать в p10 такие пакеты. А только в p11 и Сизиф.
> 
> > 
> > Вот гипотетический пример: если в соотв. пакетах, например, coreutils
> > или util-linux, просто взять и убрать все файлы вне префикса,
> > перенеся, например, /sbin/mount в /usr/sbin/mount, то:
> > - на системах со split-usr при загрузке до появления /usr файл
> >   /bin/mount будет отсутствовать;
> 
> При обновления /usr уже примонтирован.
> 
> > - такой пакет перестанет удовлетворять Requires: /sbin/mount.
> 
> Так он не соберётся в репозиторий, если не будет удовлетворять зависимостям.

Вот именно. Для ряда пакетов такие зависимости существуют, то есть их
файлы сейчас просто нельзя наивно переложить и собрать в репозиторий;
нужно формировать пакет так, чтобы он ставился на все иерархии, хотя бы
для того, чтобы он смог установиться в хешерницу на сборочнице, где
собирают другие пакеты.
Есть такой милый, бесполезный пакет lsb-core, который из таких
зависимостей в существенной степени и состоит.

Более того, в пакетах бывают post-скрипты; они пользуются программами
из /bin и /sbin, а те — библиотеками из /%_lib. Если на момент запуска
post-скрипта иерархия ещё не переведена, а пакет с программой уже
обновился и перенёс файл под префикс, то по старому пути он будет
недоступен; если его запускают без учёта PATH — процесс оборвётся.

> > Или, если речь идёт о sh и awk каких-нибудь, они часто указаны в
> > сценариях в качестве интерпретаторов: "#!/bin/awk". Файл по этому пути
> > должен быть.
> 
> Так после обновления всё уже будет.
> 
> Я не понимаю, почему мы не можем сразу же после обновления filesystem начать перенос в спеках в /usr по мере обновления пакетов, которые не планируется собирать в p10.
> Почему мы должны ждать p12?

Потому что тогда filesystem должен будет обновиться строго до того, как
эти пакеты установятся в систему, т. е. надо будет мимо rpm переносить
файлы под префикс в том виде, в котором они будут в старой системе (p10
или Sisyphus от древней даты).

В случае, если мы это делаем до обновления или перед распаковкой нового
filesystem, у нас нет способа доказать, что это возможно автоматически
сделать для ∀ возможных множеств установленных пакетов. Я задумываюсь
над тем, чтобы, если обнаруживаются неисправимые конфликты, не
игнорировать их, как сейчас, а завершаться со статусом != 0, и запускать
это в %pretrans; тогда, по идее, апгрейд тоже завершится с ошибкой до
того, как будут затронуты какие-то файлы.
(Неисправимый конфликт — это, например, /bin/ex -> vi и /usr/bin/ex ->
vim; не очевидно, какой из них стоит оставить, а какой убрать. Тут нужно
менять пакет vim. А при обновлении надо будет сначала поставить
исправленную версию, а потом повторять апгрейд.)

> почему мы не можем... начать перенос в спеках.
> почему мы должны ждать p12?
Если коротко, то:
* если получится совершать миграцию в posttrans — можем;
* если мигрировать в pretrans и заранее отказываться трогать что-либо
  при неисправимых конфликтах — тоже можем;
иначе лучше не надо.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] possible incompatibilities
  2024-02-04 12:20               ` Arseny Maslennikov
@ 2024-02-04 13:28                 ` Антон Мидюков
  0 siblings, 0 replies; 34+ messages in thread
From: Антон Мидюков @ 2024-02-04 13:28 UTC (permalink / raw)
  To: devel

04.02.2024 19:20, Arseny Maslennikov пишет:
> On Sun, Feb 04, 2024 at 05:45:23PM +0700, Антон Мидюков wrote:
>> 04.02.2024 17:30, Arseny Maslennikov пишет:
>>> On Sun, Feb 04, 2024 at 02:46:44PM +0700, Антон Мидюков wrote:
>>>> Почему самостоятельный переезд пакетов в /usr/ может сломать в будущем переезд на usr-merge?
>>>
>>> Тут надо прояснить смыслы слов.
>>>
>>> Я так понял, что переезд — это наивный перенос; взять и упаковать в
>>> другое место, из старого убрать. Такой наивный перенос файлов ломает не
>>> будущее, а обновление с прошлого.
>>
>> Да, я про такой перенос. Но перенос уже после того, как filesystem в репозитории обновлён.
>> Разумеется, я не про то, чтобы собирать в p10 такие пакеты. А только в p11 и Сизиф.
>>
>>>
>>> Вот гипотетический пример: если в соотв. пакетах, например, coreutils
>>> или util-linux, просто взять и убрать все файлы вне префикса,
>>> перенеся, например, /sbin/mount в /usr/sbin/mount, то:
>>> - на системах со split-usr при загрузке до появления /usr файл
>>>   /bin/mount будет отсутствовать;
>>
>> При обновления /usr уже примонтирован.
>>
>>> - такой пакет перестанет удовлетворять Requires: /sbin/mount.
>>
>> Так он не соберётся в репозиторий, если не будет удовлетворять зависимостям.
> 
> Вот именно. Для ряда пакетов такие зависимости существуют, то есть их
> файлы сейчас просто нельзя наивно переложить и собрать в репозиторий;
> нужно формировать пакет так, чтобы он ставился на все иерархии, хотя бы
> для того, чтобы он смог установиться в хешерницу на сборочнице, где
> собирают другие пакеты.
> Есть такой милый, бесполезный пакет lsb-core, который из таких
> зависимостей в существенной степени и состоит.
> 
> Более того, в пакетах бывают post-скрипты; они пользуются программами
> из /bin и /sbin, а те — библиотеками из /%_lib. Если на момент запуска
> post-скрипта иерархия ещё не переведена, а пакет с программой уже
> обновился и перенёс файл под префикс, то по старому пути он будет
> недоступен; если его запускают без учёта PATH — процесс оборвётся.
> 
>>> Или, если речь идёт о sh и awk каких-нибудь, они часто указаны в
>>> сценариях в качестве интерпретаторов: "#!/bin/awk". Файл по этому пути
>>> должен быть.
>>
>> Так после обновления всё уже будет.
>>
>> Я не понимаю, почему мы не можем сразу же после обновления filesystem начать перенос в спеках в /usr по мере обновления пакетов, которые не планируется собирать в p10.
>> Почему мы должны ждать p12?
> 
> Потому что тогда filesystem должен будет обновиться строго до того, как
> эти пакеты установятся в систему, т. е. надо будет мимо rpm переносить
> файлы под префикс в том виде, в котором они будут в старой системе (p10
> или Sisyphus от древней даты).

То есть при обновлении с бранча p10 до p11 установка filesystem перед dist-upgrade должно решить проблему?
Если так, то это можно прописать в инструкции обновления p10 -> p11.


> 
> В случае, если мы это делаем до обновления или перед распаковкой нового
> filesystem, у нас нет способа доказать, что это возможно автоматически
> сделать для ∀ возможных множеств установленных пакетов. Я задумываюсь
> над тем, чтобы, если обнаруживаются неисправимые конфликты, не
> игнорировать их, как сейчас, а завершаться со статусом != 0, и запускать
> это в %pretrans; тогда, по идее, апгрейд тоже завершится с ошибкой до
> того, как будут затронуты какие-то файлы.
> (Неисправимый конфликт — это, например, /bin/ex -> vi и /usr/bin/ex ->
> vim; не очевидно, какой из них стоит оставить, а какой убрать. Тут нужно
> менять пакет vim. А при обновлении надо будет сначала поставить
> исправленную версию, а потом повторять апгрейд.)
> 
>> почему мы не можем... начать перенос в спеках.
>> почему мы должны ждать p12?
> Если коротко, то:
> * если получится совершать миграцию в posttrans — можем;
> * если мигрировать в pretrans и заранее отказываться трогать что-либо
>   при неисправимых конфликтах — тоже можем;
> иначе лучше не надо.
> 
> 
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] possible incompatibilities
  2024-02-04 10:30           ` Arseny Maslennikov
  2024-02-04 10:45             ` Антон Мидюков
@ 2024-02-05  4:42             ` Ildar Mulyukov
  2024-02-05  5:10               ` Alexey V. Vissarionov
  2024-02-05 13:38               ` Arseny Maslennikov
  1 sibling, 2 replies; 34+ messages in thread
From: Ildar Mulyukov @ 2024-02-05  4:42 UTC (permalink / raw)
  To: ALT Linux Team development discussions

Добрый день,

On Sun, Feb 4, 2024 at 4:30 PM Arseny Maslennikov wrote:
>
> Я так понял, что переезд — это наивный перенос; взять и упаковать в
> другое место, из старого убрать. Такой наивный перенос файлов ломает не
> будущее, а обновление с прошлого.


Да простят мне такое наивное предложение:
не стоит ли завести виртуальную зависимость `usrmerged`, которая
присутствует только в системе, где /usr в rootfs? Это дало бы
мэйнтейнеру полную уверенность, что пакет устанавливается в уже
мигрировавшую систему. Что полезно, ИМХО.
С уважением,
-- 
Ildar Mulyukov,
(ΙΧΘΥΣ) child of God

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] possible incompatibilities
  2024-02-05  4:42             ` Ildar Mulyukov
@ 2024-02-05  5:10               ` Alexey V. Vissarionov
  2024-02-05 13:38               ` Arseny Maslennikov
  1 sibling, 0 replies; 34+ messages in thread
From: Alexey V. Vissarionov @ 2024-02-05  5:10 UTC (permalink / raw)
  To: ALT Linux Team development discussions

Good ${greeting_time}!

On 2024-02-05 10:42:56 +0600, Ildar Mulyukov wrote:

 >> Я так понял, что переезд  это наивный перенос; взять и
 >> упаковать в другое место, из старого убрать. Такой наивный
 >> перенос файлов ломает не будущее, а обновление с прошлого.
 > Да простят мне такое наивное предложение: не стоит ли завести
 > виртуальную зависимость `usrmerged`, которая присутствует только
 > в системе, где /usr в rootfs? Это дало бы мэйнтейнеру полную
 > уверенность, что пакет устанавливается в уже мигрировавшую
 > систему. Что полезно, ИМХО.

Коллеги, а вы не пробовали смотреть на этот процесс со стороны
эксплуатации? Например, попробуйте ответить на простейший вопрос:
что будет делать админ, которму нужно вотпрямщас обновить систему
хоть тушкой, хоть чучелом, столкнувшись с пакетом, которому нужна
такая зависимость?

Я уже не говорю о том, что у / и у /usr могут быть разные опции
монтирования (а других причин обособлять /usr уже не осталось).


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] I: usrmerge
  2024-02-03 14:41   ` [devel] I: usrmerge Alexey Gladkov
@ 2024-02-05  5:47     ` Anton Farygin
  0 siblings, 0 replies; 34+ messages in thread
From: Anton Farygin @ 2024-02-05  5:47 UTC (permalink / raw)
  To: devel

On 03.02.2024 17:41, Alexey Gladkov wrote:
> On Sat, Feb 03, 2024 at 10:46:42AM +0300, Anton Farygin wrote:
>> On 03.02.2024 00:38, Arseny Maslennikov wrote:
>>> Предыдущее обсуждение — в треде:
>>> https://lore.altlinux.org/devel/ZKQaFPEN0qnNWGnz@cello/
>> Ну и второй - не пора ли плавно добавить в make-initrd поддержку нового
>> расположения для /lib/firmware и /lib/modules, плавно на уровне пакетов
>> сделав нужную миграцию, поддерживающую обновления ?
> make-initrd уже умеет загружать мигрировавшие на usrmerge системы. Он
> также умеет определять, что /usr отдельный mountpoint и монировать и его.
> Это нужно для схем usrmerge + separate-usr, если у кого-нибудь такие
> остались.
>
Отлично.




^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] I: usrmerge
  2024-02-03 10:31   ` Arseny Maslennikov
@ 2024-02-05  5:48     ` Anton Farygin
  2024-02-07 15:57     ` [devel] usrmerge: future conflicts in /lib* Arseny Maslennikov
  1 sibling, 0 replies; 34+ messages in thread
From: Anton Farygin @ 2024-02-05  5:48 UTC (permalink / raw)
  To: devel

On 03.02.2024 13:31, Arseny Maslennikov wrote:
> On Sat, Feb 03, 2024 at 10:46:42AM +0300, Anton Farygin wrote:
>> On 03.02.2024 00:38, Arseny Maslennikov wrote:
>>> Предыдущее обсуждение — в треде:
>>> https://lore.altlinux.org/devel/ZKQaFPEN0qnNWGnz@cello/
>> Почему-то мне кажется что чем больше пакетов переедут самостоятельно, тем
>> меньше сложность вопросов, которые нужно будет решать в rpm и сборочной
>> системе.
> Связь тут неравномерная: ряд пакетов уже и так собираются и ставятся,
> будучи собраны с прототипом brp-модуля. Но некоторые отдельные пакеты,
> может быть, и стоит поправить заранее.
>
> Например, есть библиотеки, где под /lib64 зачем-то лежат
> devel-симлинки; или в этом каталоге лежит сама библиотека, но клиентов в
> /bin и /sbin у неё нет.
> Сейчас brp-модуль игнорирует /lib и /%_lib; если
> мейнтейнеры исправят свои такие пакеты, это поможет.
>
>
> Или, например, есть такой пакет pcc, который упаковывает файл /usr/lib/cpp.
> Путь /lib/cpp встречается в configure-скриптах из-под достаточно старых
> версий autoconf; скрипт начинает его проверять, если недоступны или
> работают не так "$CC -E" и "$CC -E -traditional-cpp".
> В debian этот путь вообще отсутствует.
> Я бы просто перед запуском такого configure-скрипта делал так:
>      sed -i 's!"/lib/cpp"!"$CC -E"!' ./configure
> А вот /usr/lib/cpp сам собой не используется вообще никем.
>
> На merged-usr иерархии пакет pcc со своим файлом /usr/lib/cpp начнёт
> иметь мисконфликт с gcc-common, чей симлинк /lib/cpp тоже попадёт в
> /usr/lib.

Ну, т.е. - как я раньше и говорил - параллельная работа по миграции 
пакетов не будет вредной, а будет скорее полезной.

Конечно, при учёте всего вышесказанного.



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] possible incompatibilities
  2024-02-05  4:42             ` Ildar Mulyukov
  2024-02-05  5:10               ` Alexey V. Vissarionov
@ 2024-02-05 13:38               ` Arseny Maslennikov
  2024-02-06  7:56                 ` Ildar Mulyukov
  1 sibling, 1 reply; 34+ messages in thread
From: Arseny Maslennikov @ 2024-02-05 13:38 UTC (permalink / raw)
  To: ALT Linux Team development discussions

[-- Attachment #1: Type: text/plain, Size: 2308 bytes --]

On Mon, Feb 05, 2024 at 10:42:56AM +0600, Ildar Mulyukov wrote:
> Добрый день,
> 
> On Sun, Feb 4, 2024 at 4:30 PM Arseny Maslennikov wrote:
> >
> > Я так понял, что переезд — это наивный перенос; взять и упаковать в
> > другое место, из старого убрать. Такой наивный перенос файлов ломает не
> > будущее, а обновление с прошлого.
> 
> Да простят мне такое наивное предложение:
> не стоит ли завести виртуальную зависимость `usrmerged`, которая
> присутствует только в системе, где /usr в rootfs? Это дало бы
> мэйнтейнеру полную уверенность, что пакет устанавливается в уже
> мигрировавшую систему. Что полезно, ИМХО.

Виртуальная зависимость, связанная со split-usr, нужна непонятно зачем.

Зависимость вида rpmlib(unmerged-usr), присутствующая только тогда,
когда /bin не символическая ссылка куда следует — не самая плохая идея,
более того, не знаю, как без этого можно сделать миграцию в posttrans,
ибо в этом случае filesystem >= 3 не должен попадать в транзакцию раньше
времени.

А вот делать на неё зависимости или конфликты в произвольных пакетах —
чудовищное зло. Как верно заметил ниже gremlin@, администраторы систем
замучаются это эксплуатировать, а мы замучаемся их в этом поддерживать.
Одни пакеты всё ещё конфликтуют с merged-usr, а другие явно его требуют.
Зачем, если мы можем сделать большую часть актуальных пакетов
совместимой с обоими ситуациями?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] possible incompatibilities
  2024-02-05 13:38               ` Arseny Maslennikov
@ 2024-02-06  7:56                 ` Ildar Mulyukov
  2024-02-06  9:36                   ` Arseny Maslennikov
  0 siblings, 1 reply; 34+ messages in thread
From: Ildar Mulyukov @ 2024-02-06  7:56 UTC (permalink / raw)
  To: ALT Linux Team development discussions

On Mon, Feb 5, 2024 at 7:38 PM Arseny Maslennikov <arseny@altlinux.org> wrote:
> Зачем, если мы можем сделать большую часть актуальных пакетов
> совместимой с обоими ситуациями?

Я что-то не понимаю, или последняя фраза эквивалентна высказыванию
"миграция на usr-merge не обязательна". Но необходимость миграции,
обоснованная в первом сообщении, ещё не опровергнута, да/нет?
С уважением,
-- 
Ildar Mulyukov,
(ΙΧΘΥΣ) child of God

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] possible incompatibilities
  2024-02-06  7:56                 ` Ildar Mulyukov
@ 2024-02-06  9:36                   ` Arseny Maslennikov
  0 siblings, 0 replies; 34+ messages in thread
From: Arseny Maslennikov @ 2024-02-06  9:36 UTC (permalink / raw)
  To: ALT Linux Team development discussions

[-- Attachment #1: Type: text/plain, Size: 778 bytes --]

On Tue, Feb 06, 2024 at 01:56:02PM +0600, Ildar Mulyukov wrote:
> On Mon, Feb 5, 2024 at 7:38 PM Arseny Maslennikov <arseny@altlinux.org> wrote:
> > Зачем, если мы можем сделать большую часть актуальных пакетов
> > совместимой с обоими ситуациями?
> 
> Я что-то не понимаю, или последняя фраза эквивалентна высказыванию
> "миграция на usr-merge не обязательна".

Вовсе нет; эта мера упрощает обновление инсталляций и существенно
облегчает задачу провести всё это в репозиторий через сборочницу.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* [devel] usrmerge: future conflicts in /lib*
  2024-02-03 10:31   ` Arseny Maslennikov
  2024-02-05  5:48     ` Anton Farygin
@ 2024-02-07 15:57     ` Arseny Maslennikov
  1 sibling, 0 replies; 34+ messages in thread
From: Arseny Maslennikov @ 2024-02-07 15:57 UTC (permalink / raw)
  To: ALT Linux Team development discussions

[-- Attachment #1: Type: text/plain, Size: 4168 bytes --]

On Sat, Feb 03, 2024 at 01:31:28PM +0300, Arseny Maslennikov wrote:
> On Sat, Feb 03, 2024 at 10:46:42AM +0300, Anton Farygin wrote:
> > On 03.02.2024 00:38, Arseny Maslennikov wrote:
> > > Предыдущее обсуждение — в треде:
> > > https://lore.altlinux.org/devel/ZKQaFPEN0qnNWGnz@cello/
> > 
> > Почему-то мне кажется что чем больше пакетов переедут самостоятельно, тем
> > меньше сложность вопросов, которые нужно будет решать в rpm и сборочной
> > системе.
> 
> Связь тут неравномерная: ряд пакетов уже и так собираются и ставятся,
> будучи собраны с прототипом brp-модуля. Но некоторые отдельные пакеты,
> может быть, и стоит поправить заранее.
> 
> Например, есть библиотеки, где под /lib64 зачем-то лежат
> devel-симлинки; или в этом каталоге лежит сама библиотека, но клиентов в
> /bin и /sbin у неё нет.
> Сейчас brp-модуль игнорирует /lib и /%_lib; если
> мейнтейнеры исправят свои такие пакеты, это поможет.

Вот список всех исходных пакетов, из которых собираются пакеты,
содержащие файлы под /lib*, которые на merged-usr иерархии начнут
конфликтовать с другими файлами:
cyrus-sasl2  asy @everybody
libdb4.7  @core
libdb4.8  rider @everybody
libdb6.1  rider @everybody
libusb  shrek shaba mike @everybody
samba  sin @qa
gcc-common  @core at sbolshakov
pcc  oddity @qa @everybody

Прошу уважаемых мейнтейнеров их исправить.

Про последние два пакета я уже писал:
> Или, например, есть такой пакет pcc, который упаковывает файл /usr/lib/cpp.
> Путь /lib/cpp встречается в configure-скриптах из-под достаточно старых
> версий autoconf; скрипт начинает его проверять, если недоступны или
> работают не так "$CC -E" и "$CC -E -traditional-cpp".
> В debian (с учётом его необычного устройства %_libdir) этот путь
> вообще отсутствует.
> Я бы просто перед запуском такого configure-скрипта делал так:
>     sed -i 's!"/lib/cpp"!"$CC -E"!' ./configure
> А вот /usr/lib/cpp сам собой не используется вообще никем.
> 
> На merged-usr иерархии пакет pcc со своим файлом /usr/lib/cpp начнёт
> иметь мисконфликт с gcc-common, чей симлинк /lib/cpp тоже попадёт в
> /usr/lib.
Полагаю, из pcc надо просто убрать /usr/lib/cpp.

Вот сами конфликтующие файлы, сгруппированные по исх. пакетам.
libdb*:
	/{,usr/}lib64/libdb-4.7.so
	/{,usr/}lib64/libdb-4.8.so
	/{,usr/}lib64/libdb-6.1.so
samba:
	/{,usr/}lib64/libnss_winbind.so.2
	/{,usr/}lib64/libnss_wins.so.2
cyrus-sasl:
	/{,usr/}lib64/libsasl2.so
libusb:
	/{,usr/}lib64/libusb-1.0.so.0

Либо эти файлы будут конфликтовать с симлинками в своих devel-пакетах,
и тогда их надо починить тем или иным надлежащим способом.
Либо конфликтующие файлы в одном пакете, и нужно положить вне префикса и
под префикс две копии вместо симлинков; например:

  cp -a %buildroot/lib64/libusb-1.0.so.0 %buildroot%_libdir/libusb-1.0.so.0

Заранее благодарю!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] I: usrmerge
  2024-02-03 10:05     ` Anton Farygin
  2024-02-03 10:21       ` Антон Мидюков
  2024-02-03 11:12       ` [devel] possible incompatibilities (was: I: usrmerge) Arseny Maslennikov
@ 2024-02-16  7:04       ` Sergey Afonin
  2024-02-16  7:08         ` Антон Мидюков
  2 siblings, 1 reply; 34+ messages in thread
From: Sergey Afonin @ 2024-02-16  7:04 UTC (permalink / raw)
  To: ALT Linux Team development discussions

On Saturday 03 February 2024, Anton Farygin wrote:

> > Но я тем не менее убеждён, что не стоит считать, что split-usr ни у кого
> > нет; иначе после начала массового перехода пакетов появятся и жалобы —
> > громкие и агрессивные, с угрозами жизни и здоровью. Очень вероятно, что
> > те, кто ставил так систему, просто не любят btrfs.
> 
> Или людей с отдельно-смонтированным /usr уже не осталось.
 
Или они не обновились до Сизифа. ;-) У меня есть такие конфигурации, их
достаточно много и, даже, две с btrfs. Но где btrfs, там вообще p9 ещё в
обоих случаях, плюс btrfs отдельным разделом под файлы отдельно взятого
приложения.

-- 
С уважением, Сергей Афонин.


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] I: usrmerge
  2024-02-16  7:04       ` [devel] I: usrmerge Sergey Afonin
@ 2024-02-16  7:08         ` Антон Мидюков
  0 siblings, 0 replies; 34+ messages in thread
From: Антон Мидюков @ 2024-02-16  7:08 UTC (permalink / raw)
  To: devel

16.02.2024 14:04, Sergey Afonin пишет:
> On Saturday 03 February 2024, Anton Farygin wrote:
> 
>>> Но я тем не менее убеждён, что не стоит считать, что split-usr ни у кого
>>> нет; иначе после начала массового перехода пакетов появятся и жалобы —
>>> громкие и агрессивные, с угрозами жизни и здоровью. Очень вероятно, что
>>> те, кто ставил так систему, просто не любят btrfs.
>>
>> Или людей с отдельно-смонтированным /usr уже не осталось.
>  
> Или они не обновились до Сизифа. ;-) У меня есть такие конфигурации, их
> достаточно много и, даже, две с btrfs. Но где btrfs, там вообще p9 ещё в
> обоих случаях, плюс btrfs отдельным разделом под файлы отдельно взятого
> приложения.
> 

В p10 и Сизифе /usr монтируется make-initrd вместе с корнем, поэтому проблемы быть не должно.

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] I: usrmerge
  2024-02-02 21:38 [devel] I: usrmerge Arseny Maslennikov
  2024-02-03  7:46 ` Anton Farygin
@ 2024-03-16 13:24 ` Arseny Maslennikov
  2024-03-27 12:54   ` Arseny Maslennikov
  1 sibling, 1 reply; 34+ messages in thread
From: Arseny Maslennikov @ 2024-03-16 13:24 UTC (permalink / raw)
  To: ALT Linux Team development discussions

[-- Attachment #1: Type: text/plain, Size: 8408 bytes --]

On Sat, Feb 03, 2024 at 12:38:44AM +0300, Arseny Maslennikov wrote:
> === Сначала о пакетах ===
> 
> Во-первых, не хотелось бы обновлять сотню пакетов в одной
> транзакции с пакетом filesystem, содержащим вместо /bin, /sbin,
> ... симлинки. Чтобы этого избежать, надо добиться, чтобы пакеты,
> кладущие что-либо в эти каталоги (вне %_prefix),
> устанавливались и на merged, и на unmerged, и на split[1].
> Для этого планируется ввести brp-модуль, который при сборке
> пакета, если в %buildroot лежит что-то в соотв. каталогах вне
> префикса, создаст копию этого файла в аналогичном месте под
> префиксом.
> Можно было бы вместо копии делать ссылку, но оказалось, что нет:
> * (упакованные в cpio) симлинк поверх файла или файл поверх симлинка нельзя
>   установить на merged-usr, т. е. поверх друг друга;
> * (упакованные в cpio) хардлинки нельзя установить на
>   split-usr-иерархию, потому что они придутся на разные ФС, и
>   rpm не сможет их расщепить (изготовить одинаковые inode).
> Это позволило снизить количество пакетов с файлами в /bin и
> /sbin, для которых потребуются ручные изменения, с 90 до ~20.
> 
> [1] https://www.altlinux.org/Usrmerge#%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9

Почти реализовано (ждём install checks).
https://git.altlinux.org/tasks/327286
Можно коммитить задание, как только будет готово к коммиту и при
отсутствии иных возражений.

Прошу одобрений от:
girar-check-perms: access to rpm-build DENIED for arseny: approved builders list: @core imz at vt
girar-check-perms: access to rpm DENIED for arseny: approved builders list: @core at imz vt
girar-check-perms: access to gzip DENIED for arseny: approved builders list: @core 
girar-check-perms: access to coreutils DENIED for arseny: approved builders list: @core 
girar-check-perms: access to gawk DENIED for arseny: approved builders list: @core 
girar-check-perms: access to util-linux DENIED for arseny: approved builders list: legion boyarsh @core
girar-check-perms: access to findutils DENIED for arseny: approved builders list: @core 
girar-check-perms: access to bzip2 DENIED for arseny: approved builders list: @core 
girar-check-perms: access to iputils DENIED for arseny: approved builders list: sem ender
girar-check-perms: access to acct DENIED for arseny: approved builders list: @core @qa
girar-check-perms: access to chrooted DENIED for arseny: approved builders list: @core 
girar-check-perms: access to genromfs DENIED for arseny: approved builders list: @core 
girar-check-perms: access to kbd DENIED for arseny: approved builders list: legion @core

glebfm@ помог провести тестовую пересборку репозитория, получающегося из
этого задания, которая помогла выявить и исправить 2 ошибки. 5 новых
пакетов не пересобрались по каким-то своим причинам; в окружении задания
выше они пересобрались.

> Мы ожидаем, что после появления rpm-build с новым brp-модулем в
> репозитории немногочисленные исправленные пакеты будут собраны в
> Sisyphus в своих индивидуальных заданиях (транзакциях), не
> создавая на сборочнице заторов на CI-проверках каждого
> подзадания.
> 
> === Теперь о миграции ===

Как только закоммитим задание выше, можно будет приступать к тому, что
ниже.
Думаю, понадобится тестовая пересборка с filesystem 3, чтобы узнать про
будущие вероятные проблемы, которые ещё не выскочили.

> После того, как все (допускаю, что за ничтожными исключениями)
> пересобираемые пакеты в Sisyphus станут устанавливаться и на
> старые иерархии, и на новые, настанет время собрать в
> репозиторий пакет filesystem (версией > 3) уже с симлинками
> вместо каталогов.
> 
> Это самая сложная часть процесса:
> * пакеты должны будут пересобираться в merged-иерархии, сейчас
>   мы это проверяем вручную;
> * чтобы он мог установиться на уже заполненный корень,
>   например, в установленную unmerged-систему, симлинки уже
>   должны быть расставлены на месте каким-то иным инструментом
>   перед тем, как rpm распакует пакет.
> 
> Мне известно два метода решения этой задачи: один реализуем точно,
> а другой умозрительно.
> * Переносить файлы и создать симлинки специальным инструментом[2]
>   прямо перед распаковкой пакета filesystem: либо в %pre этого
>   пакета, либо в %pretrans. В качестве дополнительной меры
>   предохранения попробовать добиться, чтобы filesystem
>   в rpm-транзакции стоял позже, чем другие затронутые пакеты.
> * (умозрительный способ) Добиться того, чтобы на системах с
>   unmerged-иерархией filesystem > 3 не попадал в rpm-транзакцию, а
>   специальный инструмент запускать в filetrigger после
>   транзакции, когда выяснится (каков критерий?), что все пакеты
>   обновлены до версий, подготовленных как описано в предыдущей
>   секции, и конфликтов при копировании больше не будет.
> Инструмент для слияния сводится к cp -Tal, мерам обеспечения
> атомичности замен каталогов на симлинки (файлы по своим путям
> должны быть доступны в любой момент времени), вариантам обхода
> многочисленных особых случаев в старых пакетах, с которыми сама
> команда cp -Tal не справится. При втором методе (в posttrans)
> он, в теории, может быть устроен проще, и проще доказать, что
> перенос не может сломаться ни при каком состоянии релевантного
> поддерева ФС.
> 
> [2] https://packages.altlinux.org/en/sisyphus/srpms/usrmerge/
> 
> Я пока что предполагаю, что нам придётся пользоваться первым
> методом, но не исключаю, что удастся придумать реализацию
> второго.
> 
> Предлагаю обсуждать процесс тут, если есть что обсуждать.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] I: usrmerge
  2024-03-16 13:24 ` Arseny Maslennikov
@ 2024-03-27 12:54   ` Arseny Maslennikov
  2024-06-02 21:32     ` Leonid Krivoshein
  0 siblings, 1 reply; 34+ messages in thread
From: Arseny Maslennikov @ 2024-03-27 12:54 UTC (permalink / raw)
  To: ALT Linux Team development discussions

[-- Attachment #1: Type: text/plain, Size: 3411 bytes --]

On Sat, Mar 16, 2024 at 04:24:44PM +0300, Arseny Maslennikov wrote:
> On Sat, Feb 03, 2024 at 12:38:44AM +0300, Arseny Maslennikov wrote:
> > === Сначала о пакетах ===
> > 
> > Во-первых, не хотелось бы обновлять сотню пакетов в одной
> > транзакции с пакетом filesystem, содержащим вместо /bin, /sbin,
> > ... симлинки. Чтобы этого избежать, надо добиться, чтобы пакеты,
> > кладущие что-либо в эти каталоги (вне %_prefix),
> > устанавливались и на merged, и на unmerged, и на split[1].
> > Для этого планируется ввести brp-модуль, который при сборке
> > пакета, если в %buildroot лежит что-то в соотв. каталогах вне
> > префикса, создаст копию этого файла в аналогичном месте под
> > префиксом.
> > Можно было бы вместо копии делать ссылку, но оказалось, что нет:
> > * (упакованные в cpio) симлинк поверх файла или файл поверх симлинка нельзя
> >   установить на merged-usr, т. е. поверх друг друга;
> > * (упакованные в cpio) хардлинки нельзя установить на
> >   split-usr-иерархию, потому что они придутся на разные ФС, и
> >   rpm не сможет их расщепить (изготовить одинаковые inode).
> > Это позволило снизить количество пакетов с файлами в /bin и
> > /sbin, для которых потребуются ручные изменения, с 90 до ~20.
> > 
> > [1] https://www.altlinux.org/Usrmerge#%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9
> 
> Почти реализовано (ждём install checks).
> https://git.altlinux.org/tasks/327286
> Можно коммитить задание, как только будет готово к коммиту и при
> отсутствии иных возражений.
> 
> Прошу одобрений от:

Спасибо! Одобрения получены.
Сегодня задание войдёт в репозиторий.

> 
> glebfm@ помог провести тестовую пересборку репозитория, получающегося из
> этого задания, которая помогла выявить и исправить 2 ошибки. 5 новых
> пакетов не пересобрались по каким-то своим причинам; в окружении задания
> выше они пересобрались.
> 
> > Мы ожидаем, что после появления rpm-build с новым brp-модулем в
> > репозитории немногочисленные исправленные пакеты будут собраны в
> > Sisyphus в своих индивидуальных заданиях (транзакциях), не
> > создавая на сборочнице заторов на CI-проверках каждого
> > подзадания.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] I: usrmerge
  2024-03-27 12:54   ` Arseny Maslennikov
@ 2024-06-02 21:32     ` Leonid Krivoshein
  2024-06-02 22:02       ` Arseny Maslennikov
  0 siblings, 1 reply; 34+ messages in thread
From: Leonid Krivoshein @ 2024-06-02 21:32 UTC (permalink / raw)
  To: devel

Доброго времени!


On 3/27/24 15:54, Arseny Maslennikov wrote:
> On Sat, Mar 16, 2024 at 04:24:44PM +0300, Arseny Maslennikov wrote:
>> On Sat, Feb 03, 2024 at 12:38:44AM +0300, Arseny Maslennikov wrote:
>>> === Сначала о пакетах ===
>>>
>>> Во-первых, не хотелось бы обновлять сотню пакетов в одной
>>> транзакции с пакетом filesystem, содержащим вместо /bin, /sbin,
>>> ... симлинки. Чтобы этого избежать, надо добиться, чтобы пакеты,
>>> кладущие что-либо в эти каталоги (вне %_prefix),
>>> устанавливались и на merged, и на unmerged, и на split[1].
>>> Для этого планируется ввести brp-модуль, который при сборке
>>> пакета, если в %buildroot лежит что-то в соотв. каталогах вне
>>> префикса, создаст копию этого файла в аналогичном месте под
>>> префиксом.
>>> Можно было бы вместо копии делать ссылку, но оказалось, что нет:
>>> * (упакованные в cpio) симлинк поверх файла или файл поверх симлинка нельзя
>>>    установить на merged-usr, т. е. поверх друг друга;
>>> * (упакованные в cpio) хардлинки нельзя установить на
>>>    split-usr-иерархию, потому что они придутся на разные ФС, и
>>>    rpm не сможет их расщепить (изготовить одинаковые inode).
>>> Это позволило снизить количество пакетов с файлами в /bin и
>>> /sbin, для которых потребуются ручные изменения, с 90 до ~20.
>>>
>>> [1] https://www.altlinux.org/Usrmerge#%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9
>> Почти реализовано (ждём install checks).
>> https://git.altlinux.org/tasks/327286
>> Можно коммитить задание, как только будет готово к коммиту и при
>> отсутствии иных возражений.
>>
>> Прошу одобрений от:
> Спасибо! Одобрения получены.
> Сегодня задание войдёт в репозиторий.
>

Прошу прощения за тупой вопрос, но я нигде не нашёл прямой рекомендации 
использовать в качестве шебанга, например, /usr/bin/bash. Благодаря 
симлинку ведь и старые шебанги будут корректно обрабатываться? Или не 
совсем так? А что с зависимостями на /bin/bash?


>> glebfm@ помог провести тестовую пересборку репозитория, получающегося из
>> этого задания, которая помогла выявить и исправить 2 ошибки. 5 новых
>> пакетов не пересобрались по каким-то своим причинам; в окружении задания
>> выше они пересобрались.
>>
>>> Мы ожидаем, что после появления rpm-build с новым brp-модулем в
>>> репозитории немногочисленные исправленные пакеты будут собраны в
>>> Sisyphus в своих индивидуальных заданиях (транзакциях), не
>>> создавая на сборочнице заторов на CI-проверках каждого
>>> подзадания.

-- 
WBR, Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] I: usrmerge
  2024-06-02 21:32     ` Leonid Krivoshein
@ 2024-06-02 22:02       ` Arseny Maslennikov
  2024-06-02 22:20         ` Leonid Krivoshein
  0 siblings, 1 reply; 34+ messages in thread
From: Arseny Maslennikov @ 2024-06-02 22:02 UTC (permalink / raw)
  To: ALT Linux Team development discussions

[-- Attachment #1: Type: text/plain, Size: 4491 bytes --]

On Mon, Jun 03, 2024 at 12:32:11AM +0300, Leonid Krivoshein wrote:
> Доброго времени!
> 
> 
> On 3/27/24 15:54, Arseny Maslennikov wrote:
> > On Sat, Mar 16, 2024 at 04:24:44PM +0300, Arseny Maslennikov wrote:
> > > On Sat, Feb 03, 2024 at 12:38:44AM +0300, Arseny Maslennikov wrote:
> > > > === Сначала о пакетах ===
> > > > 
> > > > Во-первых, не хотелось бы обновлять сотню пакетов в одной
> > > > транзакции с пакетом filesystem, содержащим вместо /bin, /sbin,
> > > > ... симлинки. Чтобы этого избежать, надо добиться, чтобы пакеты,
> > > > кладущие что-либо в эти каталоги (вне %_prefix),
> > > > устанавливались и на merged, и на unmerged, и на split[1].
> > > > Для этого планируется ввести brp-модуль, который при сборке
> > > > пакета, если в %buildroot лежит что-то в соотв. каталогах вне
> > > > префикса, создаст копию этого файла в аналогичном месте под
> > > > префиксом.
> > > > Можно было бы вместо копии делать ссылку, но оказалось, что нет:
> > > > * (упакованные в cpio) симлинк поверх файла или файл поверх симлинка нельзя
> > > >    установить на merged-usr, т. е. поверх друг друга;
> > > > * (упакованные в cpio) хардлинки нельзя установить на
> > > >    split-usr-иерархию, потому что они придутся на разные ФС, и
> > > >    rpm не сможет их расщепить (изготовить одинаковые inode).
> > > > Это позволило снизить количество пакетов с файлами в /bin и
> > > > /sbin, для которых потребуются ручные изменения, с 90 до ~20.
> > > > 
> > > > [1] https://www.altlinux.org/Usrmerge#%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9
> > > Почти реализовано (ждём install checks).
> > > https://git.altlinux.org/tasks/327286
> > > Можно коммитить задание, как только будет готово к коммиту и при
> > > отсутствии иных возражений.
> > > 
> > > Прошу одобрений от:
> > Спасибо! Одобрения получены.
> > Сегодня задание войдёт в репозиторий.
> > 
> 
> Прошу прощения за тупой вопрос, но я нигде не нашёл прямой рекомендации
> использовать в качестве шебанга, например, /usr/bin/bash. Благодаря симлинку
> ведь и старые шебанги будут корректно обрабатываться? Или не совсем так? А
> что с зависимостями на /bin/bash?

Работать скрипт будет одинаково вне зависимости от того, какой из двух
путей написан в первой строке после #!.

А вот с т. з. зависимостей в наших пакетах не всё равно, что туда
писать. Что в скрипте написано, на то буквально и возникнет зависимость
(по ссылке /bin и /sbin не проходит). В случае с sh и bash там обычно
путь без %_prefix.

Встречались пакеты на autotools, в которых есть вызовы AC_CHECK_PROG или
что-то подобное, которые ищут bash и находят его под /usr, а потом
генерируется зависимость на /usr/bin/bash. Пока что мы такое исправляли
установкой той переменной окружения, которая нужна (упоминается в
./configure, зависит от конкретного m4-макроса).

Я бы предпочёл просто развешать `Provides:' с этими путями, конечно.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] I: usrmerge
  2024-06-02 22:02       ` Arseny Maslennikov
@ 2024-06-02 22:20         ` Leonid Krivoshein
  2024-06-03  3:41           ` Антон Мидюков
  2024-06-03  7:54           ` Dmitry V. Levin
  0 siblings, 2 replies; 34+ messages in thread
From: Leonid Krivoshein @ 2024-06-02 22:20 UTC (permalink / raw)
  To: devel



On 6/3/24 01:02, Arseny Maslennikov wrote:
> On Mon, Jun 03, 2024 at 12:32:11AM +0300, Leonid Krivoshein wrote:
>> Доброго времени!
>>
>>
>> On 3/27/24 15:54, Arseny Maslennikov wrote:
>>> On Sat, Mar 16, 2024 at 04:24:44PM +0300, Arseny Maslennikov wrote:
>>>> On Sat, Feb 03, 2024 at 12:38:44AM +0300, Arseny Maslennikov wrote:
>>>>> === Сначала о пакетах ===
>>>>>
>>>>> Во-первых, не хотелось бы обновлять сотню пакетов в одной
>>>>> транзакции с пакетом filesystem, содержащим вместо /bin, /sbin,
>>>>> ... симлинки. Чтобы этого избежать, надо добиться, чтобы пакеты,
>>>>> кладущие что-либо в эти каталоги (вне %_prefix),
>>>>> устанавливались и на merged, и на unmerged, и на split[1].
>>>>> Для этого планируется ввести brp-модуль, который при сборке
>>>>> пакета, если в %buildroot лежит что-то в соотв. каталогах вне
>>>>> префикса, создаст копию этого файла в аналогичном месте под
>>>>> префиксом.
>>>>> Можно было бы вместо копии делать ссылку, но оказалось, что нет:
>>>>> * (упакованные в cpio) симлинк поверх файла или файл поверх симлинка нельзя
>>>>>     установить на merged-usr, т. е. поверх друг друга;
>>>>> * (упакованные в cpio) хардлинки нельзя установить на
>>>>>     split-usr-иерархию, потому что они придутся на разные ФС, и
>>>>>     rpm не сможет их расщепить (изготовить одинаковые inode).
>>>>> Это позволило снизить количество пакетов с файлами в /bin и
>>>>> /sbin, для которых потребуются ручные изменения, с 90 до ~20.
>>>>>
>>>>> [1] https://www.altlinux.org/Usrmerge#%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9
>>>> Почти реализовано (ждём install checks).
>>>> https://git.altlinux.org/tasks/327286
>>>> Можно коммитить задание, как только будет готово к коммиту и при
>>>> отсутствии иных возражений.
>>>>
>>>> Прошу одобрений от:
>>> Спасибо! Одобрения получены.
>>> Сегодня задание войдёт в репозиторий.
>>>
>> Прошу прощения за тупой вопрос, но я нигде не нашёл прямой рекомендации
>> использовать в качестве шебанга, например, /usr/bin/bash. Благодаря симлинку
>> ведь и старые шебанги будут корректно обрабатываться? Или не совсем так? А
>> что с зависимостями на /bin/bash?
> Работать скрипт будет одинаково вне зависимости от того, какой из двух
> путей написан в первой строке после #!.
>
> А вот с т. з. зависимостей в наших пакетах не всё равно, что туда
> писать. Что в скрипте написано, на то буквально и возникнет зависимость
> (по ссылке /bin и /sbin не проходит). В случае с sh и bash там обычно
> путь без %_prefix.

В этом месте я совсем запутался. (( Как правильно делать?

1. Оставлять старые шебанги с /bin или лучше менять их на /usr/bin?
2. Что из этого предпочтительно использовать в Requires: /bin/sh или 
/usr/bin/sh?
3. В Requires и в других видах зависимостей лучше не использовать макрос 
%_prefix?
4. Будут ли хоть как-то удовлетворяться зависимости по путям в /bin? 
Например, если в скрипте шебанг без /usr, а в спеке нет AutoReq: 
noshebang, будут ли корректно проставляться зависимости на /usr/bin/sh?

Отдельный интересный вопрос про скрипты, которые будут залетать в stage1 
с вероятно другой иерархией, но видимо не для этой рассылки.


> Встречались пакеты на autotools, в которых есть вызовы AC_CHECK_PROG или
> что-то подобное, которые ищут bash и находят его под /usr, а потом
> генерируется зависимость на /usr/bin/bash. Пока что мы такое исправляли
> установкой той переменной окружения, которая нужна (упоминается в
> ./configure, зависит от конкретного m4-макроса).
>
> Я бы предпочёл просто развешать `Provides:' с этими путями, конечно.

-- 
WBR, Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] I: usrmerge
  2024-06-02 22:20         ` Leonid Krivoshein
@ 2024-06-03  3:41           ` Антон Мидюков
  2024-06-03  7:54           ` Dmitry V. Levin
  1 sibling, 0 replies; 34+ messages in thread
From: Антон Мидюков @ 2024-06-03  3:41 UTC (permalink / raw)
  To: devel

03.06.2024 05:20, Leonid Krivoshein пишет:
> 
> 
> On 6/3/24 01:02, Arseny Maslennikov wrote:
>> On Mon, Jun 03, 2024 at 12:32:11AM +0300, Leonid Krivoshein wrote:
>>> Доброго времени!
>>>
>>>
>>> On 3/27/24 15:54, Arseny Maslennikov wrote:
>>>> On Sat, Mar 16, 2024 at 04:24:44PM +0300, Arseny Maslennikov wrote:
>>>>> On Sat, Feb 03, 2024 at 12:38:44AM +0300, Arseny Maslennikov wrote:
>>>>>> === Сначала о пакетах ===
>>>>>>
>>>>>> Во-первых, не хотелось бы обновлять сотню пакетов в одной
>>>>>> транзакции с пакетом filesystem, содержащим вместо /bin, /sbin,
>>>>>> ... симлинки. Чтобы этого избежать, надо добиться, чтобы пакеты,
>>>>>> кладущие что-либо в эти каталоги (вне %_prefix),
>>>>>> устанавливались и на merged, и на unmerged, и на split[1].
>>>>>> Для этого планируется ввести brp-модуль, который при сборке
>>>>>> пакета, если в %buildroot лежит что-то в соотв. каталогах вне
>>>>>> префикса, создаст копию этого файла в аналогичном месте под
>>>>>> префиксом.
>>>>>> Можно было бы вместо копии делать ссылку, но оказалось, что нет:
>>>>>> * (упакованные в cpio) симлинк поверх файла или файл поверх симлинка нельзя
>>>>>>     установить на merged-usr, т. е. поверх друг друга;
>>>>>> * (упакованные в cpio) хардлинки нельзя установить на
>>>>>>     split-usr-иерархию, потому что они придутся на разные ФС, и
>>>>>>     rpm не сможет их расщепить (изготовить одинаковые inode).
>>>>>> Это позволило снизить количество пакетов с файлами в /bin и
>>>>>> /sbin, для которых потребуются ручные изменения, с 90 до ~20.
>>>>>>
>>>>>> [1] https://www.altlinux.org/Usrmerge#%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9
>>>>> Почти реализовано (ждём install checks).
>>>>> https://git.altlinux.org/tasks/327286
>>>>> Можно коммитить задание, как только будет готово к коммиту и при
>>>>> отсутствии иных возражений.
>>>>>
>>>>> Прошу одобрений от:
>>>> Спасибо! Одобрения получены.
>>>> Сегодня задание войдёт в репозиторий.
>>>>
>>> Прошу прощения за тупой вопрос, но я нигде не нашёл прямой рекомендации
>>> использовать в качестве шебанга, например, /usr/bin/bash. Благодаря симлинку
>>> ведь и старые шебанги будут корректно обрабатываться? Или не совсем так? А
>>> что с зависимостями на /bin/bash?
>> Работать скрипт будет одинаково вне зависимости от того, какой из двух
>> путей написан в первой строке после #!.
>>
>> А вот с т. з. зависимостей в наших пакетах не всё равно, что туда
>> писать. Что в скрипте написано, на то буквально и возникнет зависимость
>> (по ссылке /bin и /sbin не проходит). В случае с sh и bash там обычно
>> путь без %_prefix.
> 
> В этом месте я совсем запутался. (( Как правильно делать?
> 
> 1. Оставлять старые шебанги с /bin или лучше менять их на /usr/bin?
> 2. Что из этого предпочтительно использовать в Requires: /bin/sh или /usr/bin/sh?
> 3. В Requires и в других видах зависимостей лучше не использовать макрос %_prefix?
> 4. Будут ли хоть как-то удовлетворяться зависимости по путям в /bin? Например, если в скрипте шебанг без /usr, а в спеке нет AutoReq: noshebang, будут ли корректно проставляться зависимости на /usr/bin/sh?
> 
> Отдельный интересный вопрос про скрипты, которые будут залетать в stage1 с вероятно другой иерархией, но видимо не для этой рассылки.
> 

В stage1, который готовит make-initrd, usr-merge иерархия. Так что никакой проблемы нет.

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] I: usrmerge
  2024-06-02 22:20         ` Leonid Krivoshein
  2024-06-03  3:41           ` Антон Мидюков
@ 2024-06-03  7:54           ` Dmitry V. Levin
  2024-06-03 12:58             ` Leonid Krivoshein
  1 sibling, 1 reply; 34+ messages in thread
From: Dmitry V. Levin @ 2024-06-03  7:54 UTC (permalink / raw)
  To: devel

On Mon, Jun 03, 2024 at 01:20:58AM +0300, Leonid Krivoshein wrote:
[...]
> 1. Оставлять старые шебанги с /bin или лучше менять их на /usr/bin?

Не менять, оставлять прежние.

> 2. Что из этого предпочтительно использовать в Requires: /bin/sh или 
> /usr/bin/sh?

Предпочтительно не указывать вручную.

> 3. В Requires и в других видах зависимостей лучше не использовать макрос 
> %_prefix?

Лучше не указывать зависимости вручную.


-- 
ldv


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [devel] I: usrmerge
  2024-06-03  7:54           ` Dmitry V. Levin
@ 2024-06-03 12:58             ` Leonid Krivoshein
  0 siblings, 0 replies; 34+ messages in thread
From: Leonid Krivoshein @ 2024-06-03 12:58 UTC (permalink / raw)
  To: devel


On 6/3/24 10:54, Dmitry V. Levin wrote:
> On Mon, Jun 03, 2024 at 01:20:58AM +0300, Leonid Krivoshein wrote:
> [...]
>> 1. Оставлять старые шебанги с /bin или лучше менять их на /usr/bin?
> Не менять, оставлять прежние.

Понял, спасибо!

>> 2. Что из этого предпочтительно использовать в Requires: /bin/sh или
>> /usr/bin/sh?
> Предпочтительно не указывать вручную.
>
>> 3. В Requires и в других видах зависимостей лучше не использовать макрос
>> %_prefix?
> Лучше не указывать зависимости вручную.

Да это всегда понятно, но при столь жёсткой схеме зависимостей не всегда 
есть возможность давать сборочнице определять их, приходится иногда 
отключать её интеллект и что-то прописывать руками, а с остальным 
подстраиваться в рантайме.

Все вопросы исключительно на тему, надо ли что-то менять в своём подходе 
к зависимостям по случаю usrmerge. Как я понял, пока в этом нет нужды. 
Тем более у меня лишь один случай с Requires: /path/to, везде даются 
имена пакетов.


-- 
WBR, Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 34+ messages in thread

end of thread, other threads:[~2024-06-03 12:58 UTC | newest]

Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-02-02 21:38 [devel] I: usrmerge Arseny Maslennikov
2024-02-03  7:46 ` Anton Farygin
2024-02-03  9:46   ` Arseny Maslennikov
2024-02-03 10:05     ` Anton Farygin
2024-02-03 10:21       ` Антон Мидюков
2024-02-03 10:57         ` Arseny Maslennikov
2024-02-03 14:44           ` Alexey Gladkov
2024-02-03 11:12       ` [devel] possible incompatibilities (was: I: usrmerge) Arseny Maslennikov
2024-02-03 15:58         ` Aleksey Novodvorsky
2024-02-04  7:46         ` [devel] possible incompatibilities Антон Мидюков
2024-02-04 10:30           ` Arseny Maslennikov
2024-02-04 10:45             ` Антон Мидюков
2024-02-04 12:20               ` Arseny Maslennikov
2024-02-04 13:28                 ` Антон Мидюков
2024-02-05  4:42             ` Ildar Mulyukov
2024-02-05  5:10               ` Alexey V. Vissarionov
2024-02-05 13:38               ` Arseny Maslennikov
2024-02-06  7:56                 ` Ildar Mulyukov
2024-02-06  9:36                   ` Arseny Maslennikov
2024-02-16  7:04       ` [devel] I: usrmerge Sergey Afonin
2024-02-16  7:08         ` Антон Мидюков
2024-02-03 10:31   ` Arseny Maslennikov
2024-02-05  5:48     ` Anton Farygin
2024-02-07 15:57     ` [devel] usrmerge: future conflicts in /lib* Arseny Maslennikov
2024-02-03 14:41   ` [devel] I: usrmerge Alexey Gladkov
2024-02-05  5:47     ` Anton Farygin
2024-03-16 13:24 ` Arseny Maslennikov
2024-03-27 12:54   ` Arseny Maslennikov
2024-06-02 21:32     ` Leonid Krivoshein
2024-06-02 22:02       ` Arseny Maslennikov
2024-06-02 22:20         ` Leonid Krivoshein
2024-06-03  3:41           ` Антон Мидюков
2024-06-03  7:54           ` Dmitry V. Levin
2024-06-03 12:58             ` Leonid Krivoshein

ALT Linux Team development discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
		devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
	public-inbox-index devel

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git