Re: [devel-distro] Тезисы для инсталлятора на базе альтератор 2.0 (промежуточный итог)

[Leonid Krivoshein <klark.devel@gmail.com>]

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

Добрый день!


On 10/14/24 07:58, Антон Мидюков wrote:
> Здравствуйте
>
> Хочу сделать промежуточный итог, чтобы разговоры не остались просто разговорами.

Однако замечу, что в заголовке приведён один из дискуссионных вопросов.


> 1. В целом у нас есть консенсус, что нам нужен конфигуратор автоустановки/автонастройки системы, принимающий на вход шаблон файла ответов для установки и выдающий на выход полностью заполненный файл ответов.

Как в других дистрибутивах более чем 20-летней давности.


> 2. У нас нет консенсуса по тому, какой формат должен использоваться для написания файла ответов для автоустановки/автонастройки. Должен быть это kickstart или всё же какой-то свой формат (например, на базе yaml). Плюс kickstart в том, что он стандартизирован и знаком многим по Red Hat, минус - обратная сторона плюса, от нас будут ожидать совместимости с kickstart там, где это невозможно.

Отдельным письмом описал и другие минусы формата ks с технической точки 
зрения.


> 3. У нас нет консенсуса по тому, нужно ли нам запускать новый конфигуратор в инсталляторе, или пусть в инсталляторе будет что-то иное, не завязанное на systemd и d-bus.

Предлагаю сначала обсудить отдельно конфигуратор.

Сейчас это более сотни модулей в репозитории, большая часть из которых 
скорее мертвы. Но это очень мало, с учётом задач программы и скорости 
поступления хотелок. Исходя из этого основная задача -- максимально 
быстрый рост кодовой базы и желание работать с этим инструментом 
разработчикам. Как минимум, это выбрасывание зависимости на guile. Но и 
архитектурить его надо "с нуля" тогда уж, начиная с конфигурационной БД 
и механизмов применения настроек к системе.

У конфигуратора в основной системе задача -- менять множество настроек 
системы. У конфигуратора в установщике -- относительно неизменный круг 
вопросов, ответы на которые должны попасть в файл ответов. То есть, 
разные задачи, разные подходы, инсталлятор не обязан быть построенным на 
основном системном конфигураторе. По крайней мере, такой вариант тоже 
стоит рассмотреть.

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


> Я вспомнил, что мы обсуждали похожую тему полгода назад:
> https://lore.altlinux.org/devel-distro/ZlMikClMGAKrPRVe@example.org/T/#t
> начало тут:
> https://lore.altlinux.org/devel/1c3dc62c-874e-4dac-9a97-43eb26454fb2@gmail.com/T/#t
>
> И в целом, идея "OEM-установки системы всегда" мне понравилась тогда. Повторюсь, что это нам даёт:
> - не нужно текущий инсталлятор переписывать, оставляем в нём только минимум шагов, всё остальное выполняется при первом запуске системы. Потом когда-нибудь напишем новый
> - можно готовить rootfs базовой системы, который разворачивать альтернативными способами. При первом запуске устанавливаются нужные компоненты. То есть не делать дважды одну и ту же работу, не заставлять пользователей систему ставить в режиме OEM. Распаковали архив, загрузчик сделали и вперёд.ребов

Если будет отказ от installer-features-stage3 в пользу конфигуратора и 
готовой rootfs, если весь код конфигурирования дистрибутива будет 
выполняться через m-p в хэшере на сборочнице, а по месту уже 
переконфигурироваться из настроенной системы, если выполняемые под 
root'ом установщиком действия будут сведены к обязательному минимуму, то 
такой подход обеспечит много преимуществ.


> 4. У нас нет консенсуса по тому, должен ли использоваться тот же файл ответов для разбивки диска, что и для файла ответов автоустановки/автонастройки системы.
> Если на пункте 3 выбрать вариант "OEM-установки системы всегда", то ответ очевиден - не должен. И эта тема тогда никак не связана с альтератор 2.0, по крайней мере на данном этапе.

Сейчас у нас профиль разметки лежит отдельно от файла ответов. Во втором 
даётся ссылка на первый и профилей авторазметки может быть несколько. 
Ответ прост: чей файл, тот и разбивалка диска либо транслятор своего 
синтаксиса в синтаксис какого-то внешнего инструмента. Так что 
разделение разумно. В качестве примера отдельного файла прицепляю 
простой профиль разбиения диска под timeshift. А если форматы совпадут, 
то вложить одно в другое на лету даже не стоит обсуждения.


-- 
WBR, Leonid Krivoshein.

[-- Attachment #2: subvol.yaml --]
[-- Type: application/x-yaml, Size: 1304 bytes --]