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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1728556173; x=1729160973; darn=lists.altlinux.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=xa5cBTmZEXvrrc6/AOvrMIWs1FECdlujTzO7DMz4RNM=; b=DHgU01Zp4GVAR/5LOgBVxfeRR3ipFf6nERw1YPPJ0+bmW7AVEYTRxLxfYRIyutkJKr jiXXB/i5y4pjObqGD9+RGJZGHiZ6K1e19j+rovZDaZJ2alztgj63ld3do/7Jc0/koOxL MtV5lxMF6UDQgV3Xd9cdFlUB+LndKdaA0Sx2i9iRsOt7lPRqDQt1qspIuT87FNFXrD80 owG+j3seFIzveFR1aXL0LNzmeks8wDwBwGJ2ZTJYkCvAsBt57EfmSGcDXLCOLv10rVLu HcljBkEwYFXkf9MkWV5JHpW3zFUWounFmZJuJsHKMyElXvP/zFq8hyes53vUuEsHtCfO Vp0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728556173; x=1729160973; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=xa5cBTmZEXvrrc6/AOvrMIWs1FECdlujTzO7DMz4RNM=; b=CporPkvj6rK67Msy37O9TNG2MsCnAYhcGNpN7dy6VGoCszsz4Zgb/bqo++JhoMekBr UpcEIbWcIieO+2MAxWqpJ+RhVnxYMhn/21y3HIt+CGWLiRceiSjLZp8HUyaGu1enTPtb XeNLRK7c+Kt+s8NiRnp1mI7yd0o3DC7iosXaKU30rrgIX8xd5s96Fvs/C/1HBkJCoWMj yL6MNKpTC8g7sH8qOG2c2LQEdIU+nRNsNf+VER7OQxDAzwtYY3beoh56veC2Z58yzQvK oPtnz2vWsyDQllEv8JRI8Cvk9SVnHWTeBrbich6L4eC24Xt6OyA0rvkotBmCs++Pu0KO qOzA== X-Gm-Message-State: AOJu0YyiMvGznvh7m3NHFfnkYpLOL9zgc2gNXNyptce9miHXj7CSrNGa 6kGV6qqLGNyskBRFmSA/kE8fh0F2kYFqHkZ+9F+fxQkK1HWJnyR/g4uoSw== X-Google-Smtp-Source: AGHT+IE9lXx24reKP+r6cFdq1Wqe0XRuL5Cf3lnkRkEOF6g9BdXMIAwb293aoXEI2mTMNpJY0WJWFQ== X-Received: by 2002:a05:6512:33ce:b0:52e:9481:eaa1 with SMTP id 2adb3069b0e04-539c48a01e5mr3676456e87.23.1728556172506; Thu, 10 Oct 2024 03:29:32 -0700 (PDT) Message-ID: <48789387-1646-4dd8-b5fa-52f487557f6e@gmail.com> Date: Thu, 10 Oct 2024 13:29:30 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: devel-distro@lists.altlinux.org References: Content-Language: ru, en-US From: Leonid Krivoshein In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: Thu, 10 Oct 2024 10:29:36 -0000 Archived-At: List-Archive: 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.