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

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

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.

Но. Многое зависит от того, что будет с конфигуратором, какими данными 
он будет манипулировать и будет ли он связан с установщиком.

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

Да. Только не конфигуратор, а установщик. Или уж тогда та часть 
установщика, что отвечает за ручное конфигурирование.

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

Да. Но если ради нескольких шагов, то усложнение того не стоит.


> и установки пакетов.
> На первый взгляд не вижу ничего такого.

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


-- 
WBR, Leonid Krivoshein.