[devel-distro] Тезисы для инсталлятора на базе альтератор 2.0

[Антон Мидюков]

10.10.2024 01:08, Leonid Krivoshein пишет:
> 
> On 10/9/24 09:19, Ivan A. Melnikov wrote:
>> On Tue, Oct 08, 2024 at 04:43:47PM GMT, Антон Мидюков wrote:
>>> Доброго времени суток
>>>
>>> Три недели назад обсуждали в составе: sin@ cas@ sem@ shaba@ antohami@,
>>> каким должен быть новый инсталлятор на базе альтератор 2.0.
>> Во-первых, я апплодирую, потому что, хотя я и не участвовал в этом
>> обсуждении, на днях я доказывал sin@, что нужно делать примерно
>> то же самое.
>>
>>> По результатам обсуждения я сформулировал следующие тезисы:
>>> 1. Графический интерфейс инсталлятора представляет собой конфигуратор,
>>> который создаёт сценарий автоустановки (kickstart-файл)
>> Я не считаю, что у нас возможна совместимость с redhat в этом вопросе.
>> Поэтому я предлагаю придумать этому файлу другой формат и название.
>> Взяв у коллег лучшее, естественно.
>>
>> Формат должен быть документирован, его корректность и наличие
>> всех необходимых полей должны быть проверяемы программно (т.е.
>> нужна схема).
> 
> Да. Yaml. СхемЫ тоже на Yaml. Есть возражения? Во множественном, т.к. модульность, схемы будут разделены по пакетам. Важна строгая типизация, давно обсуждали это и кажется Иван Захарящев даже что-то делал для этого с woo.
> 
> Но. Многое зависит от того, что будет с конфигуратором, какими данными он будет манипулировать и будет ли он связан с установщиком.

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

> 
>>> 2. Сценарий автоустановки состоит из секций конфигураций,
>>> соответствующих бекенду. Если бекенд не доступен, секция конфига
>>> пропускается
>> С этим пунктом я не согласен. Лучше явно помечать, в каких условиях должен
>> выполняться каждый шаг. Во-первых, explicit is better than implicit (c).
>> Во-вторых, это позволит конфигуратору (графическому, хотя и не
>> обязательно) не пытаться идти и выяснять, какие бекенды есть, а просто
>> делать свою работу.
>>
>> В целом, конфигуратор я представляю себе как инструмент, получающий
>> на вход шаблон сценария автоустановки и, возможно, режим работы
>> (установка/настройка первого запуска/...), и дозаполняющий в нужных
>> шагах необходимые поля. Грубо говоря, файл на входе, файл на выходе.
>> Легко писать, легко тестировать, легко пилить альтернативные
>> реализации.
> 
> Да. Только не конфигуратор, а установщик. Или уж тогда та часть установщика, что отвечает за ручное конфигурирование.
> 

Почему ты так считаешь? Вполне здравая идея, что конфигуратор - инструмент для заполнения сценария автоустановки. На вход может быть подан полностью или частично заполненный сценарий автоустановки, а конфигуратор будет позволять его отредактировать и выдать новый вариант. То есть у дистрибутива будет уже заранее подготовленный сценарий автоустановки с некоторыми дефолтами. Пользователю нужно будет их поменять. Если конфигуратор будет запускаться отдельно от инсталлятора, то он будет позволять загрузить некий сценарий автоустановки и сохранить на выходе новый. Если в составе инсталлятора, то помимо этого появляется возможность произвести установку. В режиме автоустановки конфигуратор конечно же запускаться не должен (чтобы графика была не нужна).
Но на первом этапе нам не нужно делать графический инсталлятор. Нам достаточно реализовать отдельно конфигуратор и модуль интерпретации сценария автоустановки.

>>> 3. Один и тот же сценарий автоустановки может использоваться для
>>> установки и запуска настройки первого запуска [...]
>> Опять же да, но мне кажется, что если нужного бекенда нет, это
>> ошибка, а применимость шага в конкретном сценарии должна быть
>> явно отмечена.
>>
>>> 8. Настройки выполняются параллельно
>> Это важно и было бы круто. Нужно продумать, могут ли быть
>> зависимости между шагами установки, помимо очевидной
>> зависимости ВСЕГО от разбивки диска
> 
> Да. Но если ради нескольких шагов, то усложнение того не стоит.
> 
> 
>> и установки пакетов.
>> На первый взгляд не вижу ничего такого.
> 
> Установка большого числа пакетов из установщика, вероятно, не самое лучшее на сегодняшний день решение. Такой шаг уместней в конфигураторе из установленной системы после обновления. И тянуть не из repo-main, а по сети.
> 

Установка дополнительных пакетов должна быть возможна, как при установке, так и при первом запуске. Это опциональный шаг, который может: совсем не быть, быть только в конфигураторе перед установкой, в конфигураторе после установки, в обоих конфигураторах. То есть как и любой другой шаг, о чём писал в заглавном письме.


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