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

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

09.10.2024 09:19, Ivan A. Melnikov пишет:
> On Tue, Oct 08, 2024 at 04:43:47PM GMT, Антон Мидюков wrote:
>> Доброго времени суток
>>
> 
>> Три недели назад обсуждали в составе: sin@ cas@ sem@ shaba@ antohami@,
>> каким должен быть новый инсталлятор на базе альтератор 2.0.
> 
> Во-первых, я апплодирую, потому что, хотя я и не участвовал в этом
> обсуждении, на днях я доказывал sin@, что нужно делать примерно
> то же самое.
> 
>> По результатам обсуждения я сформулировал следующие тезисы:

Это  скорее конспект тех мыслей, что озвучивались, то есть не мои мысли.

> 
>> 1. Графический интерфейс инсталлятора представляет собой конфигуратор,
>> который создаёт сценарий автоустановки (kickstart-файл)
> 
> Я не считаю, что у нас возможна совместимость с redhat в этом вопросе.
> Поэтому я предлагаю придумать этому файлу другой формат и название.
> Взяв у коллег лучшее, естественно.
> 
> Формат должен быть документирован, его корректность и наличие
> всех необходимых полей должны быть проверяемы программно (т.е.
> нужна схема).
> 

Согласен.

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

Мне эта идея нравится.

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

Наш старый альтератор, кстати, пропускает недоступные шаги.
Но да, лучше определять формат на входе. Можно опциональность в параметре определять, то есть на входе.

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

На этапе конфигурирования зависимостей быть не должно. Шаги должны располагаться в плане удобства. Я пока слабо представляю, как это всё удобно сделать в плане UI.
Видимо, должен быть отдельный конфиг определяющий их расположение. Но это будет зависеть от того, как будет выглядеть UI.
Шаг выбора языка должен быть выбран при старте, чтобы можно было задать нужный язык инсталлятора, как сейчас. 
А вот на этапе установки, то есть интерпретирования, можно выполнять секции по очереди, тем самым и задавать порядок.

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