From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.1 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ya.ru; s=mail; t=1728458505; bh=pyBvhB/4cwaVNQyQwlQgEInekFgd1LT/ZoyoRj5B0qE=; h=In-Reply-To:From:Date:References:To:Subject:Message-ID; b=WM9BCB9D2SMo6fY27t552fhqys0tkYlHBSF1xIs+UARToW4ZNNUjvtTramEj/1j5N It8ywj/lNQjy24zcjtrRnygRd1E3YWneZxJmT54jYPKB0K3F/Yd9XfTmSpsPyM83gG 07bXJZMZ0ea3uz70NC7GWaQErrvx5Jjbz8qe3whQ= Authentication-Results: mail-nwsmtp-smtp-production-main-84.vla.yp-c.yandex.net; dkim=pass header.i=@ya.ru Message-ID: Date: Wed, 9 Oct 2024 10:21:45 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: devel-distro@lists.altlinux.org References: Content-Language: ru From: =?UTF-8?B?0JDQvdGC0L7QvSDQnNC40LTRjtC60L7Qsg==?= In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Yandex-Filter: 1 Subject: Re: [devel-distro] =?utf-8?b?0KLQtdC30LjRgdGLINC00LvRjyDQuNC90YHRgtCw?= =?utf-8?b?0LvQu9GP0YLQvtGA0LAg0L3QsCDQsdCw0LfQtSDQsNC70YzRgtC10YDQsNGC?= =?utf-8?b?0L7RgCAyLjA=?= X-BeenThere: devel-distro@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Distributions development List-Id: Distributions development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2024 07:21:49 -0000 Archived-At: List-Archive: 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. Шаг выбора языка должен быть выбран при старте, чтобы можно было задать нужный язык инсталлятора, как сейчас. А вот на этапе установки, то есть интерпретирования, можно выполнять секции по очереди, тем самым и задавать порядок. -- С уважением, Антон Мидюков