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

[Leonid Krivoshein]

On 10/10/24 08:26, Антон Мидюков wrote:
> 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 бекендов, после чего производить эти самые вызовы. В итоге будет происходить установка. Выполнение этапов автоустановки должно визуализироваться. При графической установке это фронтенд инсталлятора. При автоустановке - сообщения в консоль.

Про API и разделение на ф/б-енды отдельно напишу.


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

Выше я прочитал "конфигуратор... автоустанавливает", вопрос терминологии.


> Вполне здравая идея, что конфигуратор - инструмент для заполнения сценария автоустановки.

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

Стоит рассмотреть и другие сценарии, когда установщик и конфигуратор 
(центр управления системой) вообще никак не связаны.


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

Чтобы не было путаницы в терминологии, уточнил: конфигуратор или та 
часть установщика, что отвечает за ручное конфигурирование, это зависит 
от интеграции между центром управления системой (конфигуратором) и 
установщиком.


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

Вопрос в пользе repo-main и целесообразности по-пакетной установки через 
apt'овый pipe каждого RPM-пакета в современном установщике. В 
рекомендуемом дистростроителем способе поддержки ОС, установленный таким 
способом RPM-пакет с вероятностью 99.9% должен быть сразу заменён, мы 
просто тратим время на его не нужную установку очень медленным способом.

В начале 2000-х, когда ADSL был ещё не у всех, это было способом увезти 
на диске в свой мухосранск пакетную базу хоть какой-то давности. В 
современном мире для любителей изолированных контуров есть локальное 
зеркало и можно специально для таких сделать премиум подписку по почте 
на ежемесячный срез репозитория, записанный на BlueRay или даже на 
USB-флешку с фирменной символикой.


-- 
WBR, Leonid Krivoshein.