From: Leonid Krivoshein <klark.devel@gmail.com> To: devel-distro@lists.altlinux.org Subject: Re: [devel-distro] Тезисы для инсталлятора на базе альтератор 2.0 Date: Thu, 10 Oct 2024 13:29:30 +0300 Message-ID: <48789387-1646-4dd8-b5fa-52f487557f6e@gmail.com> (raw) In-Reply-To: <e57542f7-b8ba-4f3a-b2b2-16d6e071139a@ya.ru> 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.
next prev parent reply other threads:[~2024-10-10 10:29 UTC|newest] Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-10-08 13:43 Антон Мидюков 2024-10-08 23:13 ` [devel-distro] " Leonid Krivoshein 2024-10-08 23:29 ` [devel-distro] Тезисы для инсталлятора " Leonid Krivoshein 2024-10-09 2:13 ` Evgeny Sinelnikov 2024-10-09 21:52 ` Leonid Krivoshein 2024-10-14 7:17 ` [devel-distro] " Sergey V Turchin 2024-10-14 19:57 ` [devel-distro] Интерфейсы " Evgeny Sinelnikov 2024-10-14 21:23 ` Leonid Krivoshein 2024-10-14 21:57 ` Антон Мидюков 2024-10-15 1:11 ` Leonid Krivoshein 2024-10-15 4:49 ` Anton Farygin 2024-10-15 9:44 ` Michael Shigorin 2024-10-15 15:05 ` Denis Medvedev 2024-10-16 0:25 ` Leonid Krivoshein 2024-10-17 7:22 ` [devel-distro] " Sergey V Turchin 2024-10-15 19:29 ` [devel-distro] " Leonid Krivoshein 2024-10-17 7:27 ` [devel-distro] " Sergey V Turchin 2024-10-18 9:05 ` [devel-distro] [JT] мировоззренческое по путям развития Michael Shigorin 2024-10-15 5:19 ` [devel-distro] Интерфейсы для инсталлятора на базе альтератор 2.0 Evgeny Sinelnikov 2024-10-15 23:02 ` Leonid Krivoshein 2024-10-15 10:30 ` [devel-distro] инсталятор как краеугольный камень выбора технологического пути Michael Shigorin 2024-10-09 1:40 ` [devel-distro] Installator 2.0: конфигуратор, создающий kickstart-файл Leonid Krivoshein 2024-10-09 9:06 ` [devel-distro] " Sergey V Turchin 2024-10-09 19:46 ` [devel-distro] " Leonid Krivoshein 2024-10-10 19:29 ` [devel-distro] про API и фронтэнды Leonid Krivoshein 2024-10-10 23:27 ` Антон Мидюков 2024-10-11 0:33 ` Leonid Krivoshein 2024-10-14 7:27 ` Sergey V Turchin 2024-10-15 4:59 ` [devel-distro] Веб-браузер в инсталляторе или для инсталлятора? Evgeny Sinelnikov 2024-10-15 5:53 ` Антон Мидюков 2024-10-15 20:53 ` Leonid Krivoshein 2024-10-18 9:25 ` Michael Shigorin 2024-10-14 7:22 ` [devel-distro] Re: Installator 2.0: конфигуратор, создающий kickstart-файл Sergey V Turchin 2024-10-14 19:58 ` [devel-distro] " Leonid Krivoshein 2024-10-15 4:52 ` Anton Farygin 2024-10-15 19:30 ` Leonid Krivoshein 2024-10-15 6:33 ` [devel-distro] " Sergey V Turchin 2024-10-17 7:32 ` [devel-distro] " Sergey V Turchin 2024-10-17 7:49 ` [devel-distro] " Антон Мидюков 2024-10-17 8:44 ` [devel-distro] " Sergey V Turchin 2024-10-18 8:56 ` [devel-distro] qtbrowser vs wasm Michael Shigorin 2024-10-15 10:03 ` [devel-distro] [JT] Re: Installator 2.0: конфигуратор, создающий kickstart-файл Michael Shigorin 2024-10-15 23:49 ` Leonid Krivoshein 2024-10-16 8:52 ` Michael Shigorin 2024-10-14 7:43 ` [devel-distro] " Sergey V Turchin 2024-10-14 10:54 ` [devel-distro] " Sergey V Turchin 2024-10-09 9:49 ` [devel-distro] " Alexey Gladkov 2024-10-09 19:54 ` Leonid Krivoshein 2024-10-10 9:10 ` Alexey Gladkov 2024-10-10 12:21 ` Leonid Krivoshein 2024-10-10 14:31 ` Alexey Gladkov 2024-10-09 6:19 ` [devel-distro] Тезисы для инсталлятора на базе альтератор 2.0 Ivan A. Melnikov 2024-10-09 7:21 ` Антон Мидюков 2024-10-09 9:21 ` [devel-distro] " Sergey V Turchin 2024-10-09 13:08 ` [devel-distro] " Leonid Krivoshein 2024-10-09 13:56 ` [devel-distro] о голосовом управлении (was: Тезисы для инст, альтератор 2.0) Arseny Maslennikov 2024-10-10 8:11 ` [devel-distro] о голосовом управлении Антон Мидюков 2024-10-14 7:33 ` [devel-distro] Re: Тезисы для инсталлятора на базе альтератор 2.0 Sergey V Turchin 2024-10-09 22:08 ` [devel-distro] " Leonid Krivoshein 2024-10-10 1:01 ` [devel-distro] Пример файла разметки и описания Leonid Krivoshein 2024-10-10 8:54 ` Антон Мидюков 2024-10-10 5:26 ` [devel-distro] Тезисы для инсталлятора на базе альтератор 2.0 Антон Мидюков 2024-10-10 10:29 ` Leonid Krivoshein [this message] 2024-10-14 4:58 ` [devel-distro] Тезисы для инсталлятора на базе альтератор 2.0 (промежуточный итог) Антон Мидюков 2024-10-14 18:59 ` Leonid Krivoshein
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=48789387-1646-4dd8-b5fa-52f487557f6e@gmail.com \ --to=klark.devel@gmail.com \ --cc=devel-distro@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Distributions development This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel-distro/0 devel-distro/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel-distro devel-distro/ http://lore.altlinux.org/devel-distro \ devel-distro@lists.altlinux.org devel-distro@lists.altlinux.ru devel-distro@lists.altlinux.com public-inbox-index devel-distro Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel-distro AGPL code for this site: git clone https://public-inbox.org/public-inbox.git