Installer/todo: различия между версиями
Нет описания правки |
PhpCoder (обсуждение | вклад) м (Исправил заголовок.) |
||
Строка 17: | Строка 17: | ||
* упрощённый переход между шагами [https://bugzilla.altlinux.org/show_bug.cgi?id=14456 14456] | * упрощённый переход между шагами [https://bugzilla.altlinux.org/show_bug.cgi?id=14456 14456] | ||
=== Мысли про autoinstall === | |||
*То что сейчас существует это не какая-то отдельно сделанная технология, | *То что сейчас существует это не какая-то отдельно сделанная технология, | ||
это скорее побочный эффект того как работает сам alterator (достаточно | это скорее побочный эффект того как работает сам alterator (достаточно |
Версия от 10:14, 13 августа 2008
Планы на будущее
Новый функционал
- инсталлятор, запускающийся из-под live-cd.
- инсталлятор с web-интерфейсом: перенос workflow-acc в пакет alterator-standalone, создание workflow-wizard.
- режим работы: сначала создать профиль автоустановки, а потом запустить установку.
- установка при помощи заранее подготовленного профиля, редактор профиля
Известные проблемы
- возможность отключения автодетекта монитора (параметр xmonitor)
- все новые профили должны provides/obsoletes предыдущие 11907 и 11906
- упрощённый переход между шагами 14456
Мысли про autoinstall
- То что сейчас существует это не какая-то отдельно сделанная технология,
это скорее побочный эффект того как работает сам alterator (достаточно посмотреть на размер пакета alterator-autoinstall)
- Я так и не понял хотим ли мы какой-то свой особенный формат или хотим формат в стиле RH/SuSE.
- Не было времени изучить все последние веяния на этом поприще (а то сделаем себе kickstart, а RH убежит вперёд) и оценить си
туацию.
- Не было заказа с пометкой "срочно, это единственный выход".
- Отдельные модули, типа vm генерят достаточно мутный набор команд и используют свой особенный дополнительный профиль.
- Надо по хорошему autoinstall сопровождать модулем по созданию autoinstall по аналогии с RH.
- Чтобы профиль был после работы инсталлятора, то по хорошему надо изменять стиль его работы, а для этого надо понять какие модули мы оставляем интерактивными ибо иначе нельзя, а какие будут просто генерить команды для kickstart.Пока мысли такие:
- всё что идёт на третьей стадии (внутри уже установленной системы) можно переделать на kickstart
- всё что идёт на второй стадии должно остаться интерактивным, но перенос настроек будет делаться при помощи сгенерённого kickstart.
При таком подходе есть шанс взять этот интеграл "по частям".