[Devel-conf] Тюнинг инсталлятора

Вт Окт 16 03:46:16 MSD 2007

Здравствуйте,

On 10/15/07, Stanislav Ievlev <stanislav.ievlev на gmail.com> wrote:
>
> Для начала большая просьба разрывать тред, если начинается новая тема.
>
> А вот мои варианты ответа.
>
> 1. Сейчас есть проблема - из-за использования http или надо городить
> файл типа index или дословно перечислять содержимое Metadata в
> инсталляторе.
>
> В инсталляторах от server и desktop использовался второй подход.
>
> Я пока представляю единственный способ снять подобное ограничение, а
> заодно и воплотить мечту о возвращении фичи инсталлятора Mandrake,
> когда его можно было "пропатчивать". Это замена каталога Metadata, а
> архив (видимо zip, чтобы его можно было сделать при необходимости из
> под разных систем, а может быть tar?).

Мне кажется,что замена каталога на архив несколько  усложняет весь процесс,
поскольку требует для кастомизации  процесса  дополнитльных действий по
распакаовке и упаковке содержимого меняющего этот процесс. По моему,
добавление набора файлов и сам факт их наличия уже есть патчинг...  смысл
идеи был в следующем: при наличии модуля альтератора, умеющего "проигрывать"
некоторые сценарии, кастомизация может выглядеть как добавление файла
autoinstall.scm, в котором между этапами установки добавлен этот модуль, с
параметром указывающим на имя файла, который копируется рядом с
autoinstall.scm. Но проблемный вопрос состоял в том, как из этого скрипта
получить в чруте доступ в дополнительным файлам, например архивов, которые
также складываются, в случае кастомизации, в каталог Metadata. Замена же
Metadata на архив нерешает этого вопроса.

Тут есть ещё такое препятствие как некоторое опасение с тем чтобы
> распространять unionfs на почти всю файловую систему. Полного "патча"
> в связи с этим видимон не получится ... в общем пока не знаю.

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

2. Для модификации autoinstall.scm перед его исполнением я думаю
> сделать  какой-нибудь hook, чтобы можно было сначала сформировать
> autoinstall, а потом его исполнить. Тут мне надо тоже некоторое время
> на подумать, чтобы понять куда его запихнуть ...

я думал о том, чтобы, при наличии подкаталогов preinstall.d и
postinstall.dв каталоге Metadata, скрипты находящиеся в них могли бы
запускаться на равне
с теми скриптами, которые лежат в образе. Вариантов я тут вижу два:
копировать вс скрипты в один каталог в некотором порядке, напрример так,
чтобы скрипты из Metadata перезаписывали скрипты из образа, или выполнять их
из разных каталогов, причем при наличии скрипта с одним и тем же именем
выполнять тот, который лежит в Metadata.

Запуск своего набора, подготовленнных скриптов, может обеспечить должную
модификацию autoinstall.scm до начала его интерпретации. К сожалению, этот
подход не решает пока той проблемы, что при интерпретации
autoinstall.scmиксы не запускаются, и соотвественно нельзя вызвать
нативный ui,
соотвествующего модуля в графическом режиме. И если я всё правильно понимаю
текущии модули не имеют ui для работы в текстовом режиме, что уже почти
спасло бы ситуацию...

В общем ваши патчи  (но именно патчи, а не хаки;)) ) могут значительно
> ускорить разработку ;)
>
> 13.10.07, Evgeny Sinelnikov<sin на altlinux.ru> написал(а):
>
> > следующие вопросы относительно новой версии installer:
> > 1. имеется ли возможность запуска preinstall.d и postinstall.d скриптов
> из
> > каталога Metadata. Этот вопрос возник в связи с желанием сделать модуль
> > альтератора, запускающего произвольный скрипт, что позволило бы вписать
> в
> > autoinstall.scm строку  вида:
> > (("script") language ("ru_RU") action "run" name "/path/to/script")
> > и получить произвольное переконфигурирование процеса инсталяции на любой
> его
> > стадии... Но тут есть два не ясных вопроса: можно ли указывать
> относительный
> > путь к скрипту, если да, то откуда тогда этот путь будет высчитываться?
> > иначе же, когда путь абсолютный, возникает вопрос о пути к скрипту при
> его
> > запуске из чрута или до него.... ещё один момент, из этой же серии,
> > возникает в связи с поиском в чруте и до него не только самого скрипта,
> но и
> > дополнительных файлов, которые могут для этого скрипта понадобться
> > (например, архив с настройками, которые собственно и предполагается
> > распаковать в установленную систему).
> > 2. ещё один вопрос, который не совсем понятен - это передача парметров
> между
> > различными этапами установки, например передача имени устройства, на
> которое
> > нужно установить заргрузчик, после автоматической разбивки диска
> (заранее не
> > известно будет это hda, sda или может быть sdb3)... Насколько я смог
> > рассмотреть autoinstall.scm из mkai.git, сейчас модуль lilo умеет
> принимать
> > в качестве параметра #t - видимо, это то, что нужно, но на stage2 из
> > установочного диска ALT Linux Desktop 4.0 - это не работает....
> >
> > Поводя итог, хочу сказать, что идельным вариантом тонкой настройки
> установки
> > дистрибутива я вижу возможность не только создавать свой профиль
> > установщика, но и возможность тонкой модификации процесса установки
> путём
> > подкладывания нужных файлов, например, в каталог Metadata. Этот процесс
> я
> > вижу себе таким. После получения коробки с дистрибутивом, образ
> копируется,
> > изменяется iso-редактором, например путём подкладывания одного файла
> > autoinstall.scm в каталог Metadata и после прожига получается
> автоматически
> > устанавливаемый инсталятор, со своими стандартными настройками.
> Единсnвенной
> > проблемой здесь, является частичная настройка, поскольку в текущем
> варианте,
> > при использовании autoinstall.scm нельзя пропустить часть вопросов,
> оставив,
> > например, только выбор разбивки дисков.
> >
> > --
> > Sin (Sinelnikov Evgeny)
> > _______________________________________________
> > devel-conf mailing list
> > devel-conf на lists.altlinux.org
> > https://lists.altlinux.org/mailman/listinfo/devel-conf
> >
>

-- 
Sin (Sinelnikov Evgeny)
----------- следующая часть -----------
Вложение в формате HTML было удалено...
URL: <http://lists.altlinux.org/pipermail/devel-conf/attachments/20071016/f9f69c3f/attachment-0002.html>