почему установку рограммы он делает в chroot, но настройку делает в рабочей системе? в чем профит?
Плюсы:
# Вся структура системы находится в едином squash-файле.
# Все то, что устанавливается в режиме cl-builder
вносит изменения в директорию /delta
(по дефолту находящуюся в корне)
# Все изменения в системе, такие как конфиги, данные в /var, возможно измененные вами собственноручно скрипты в /usr и т.п. находятся в /workspace
Это четкое разграничение позволяет с одной стороны создать iso-образ обновленной системы БЕЗ всех тех изменений внесенных в работающей системе, допустим без лишних пользователей в /etc/{passwd,shadow,groups}
, вообще с конфигами в /etc
и данными в /var
без изменений специфичных для системы на вашем компе, или с ними, если вы их оформите в шаблонах, или просто перенесете в /mnt/builder
С другой стороны - можно быстро создать бэкап вашей системы без необходимости сохранять кучу файлов находящихся на всех iso-шках.
Вот к примеру размеры структур образующих мою систему
# for p in /mnt/scratch/{workspace/,livecd.squashfs,delta/}; do du -sh `readlink -f $p`; done
25M /mnt/scratch/workspace
1.9G /mnt/scratch/cldg-20121113-i686-64G/livecd.squashfs
934M /mnt/scratch/cldg-20121113-i686-64G/delta
### при этом
# du -hs /mnt/scratch/delta/usr/portage/
624M /mnt/scratch/delta/usr/portage/
В моем случае - как я тут писал, обновление превращается в распаковку iso-шки и изменение симлинка
Также теперь можно забэкапить /mnt/scratch/workspace
или просто заглянуть в него, и разобраться что где и как в изменено шаблонами
также, перед началом обновления, можно забэкапить /mnt/scratch/delta
, если он конечно не пустой, и начать мучить систему изменять набор софта и USE-флаги по вашему усмотрению, не опасаясь получить неработоспособную систему (точнее - имея возможность привести ее в исходное состояние)
Другой более извращенный вариант - можно перемонтировать /mnt/builder с другим “верхним слоем” и в нем производить изменения софта. в этом случае не придется даже бекапов делать(экономия места на харде). Единственный минус - на данный момент объединение всех слоев потребует некоторого знания aufs и времени.
тогда это становится фишкой кальки - почему об этом не пишем?
некрасиво за других отвечать, но я думаю потому что этот функционал изначально не задумывался, и требует либо написания многих скриптов (и документации к ним), либо много ручной работы, которую тоже где-то надо расписать
многим для экспериментов нужна неубиваемая система,
ну вот выше я и расписал как это делается
… на сервера например,
у себя на сервере я запускаю некоторые службы в виртуалках поднятых через lxc
на подобных многослойных фс-ах (директории с данными и неизменяемыми конфигами само собой через bind с оригинальной fs, для надежности и упрощения бэкапов).
Где-то в блоге кажется я описывал общий принцип. Выкладывать свое решение пока не буду, на данный момент - это набор страшных (но работоспособных) костылей.
Как руки дойдут - оформлю их в приличные скрипты, может даже модуль + набор шаблонов для calculate-3 напишу, думаю это будет лучший вариант.