Установка изначально подобранного набора софта без необходимости создавать доп. ISO-шки

Очередной пост про то как не хватает пользователям минимальной установки

У что самое интересное - я с автором и его предшественниками абсолютно согласен. Сам порою делал монструозные сборки с ОгнеЛисом и Хромом, почтовым Буревестником, вином, inkscape-ом и полным набором плагинов для gimp-а из sunrise (а что, мало ли кому показывать придется, вот допустим одного дезигнера сильно заинтересовал калькой, а ему голого GIMP-а мало, ему еще и CMYK как минимум нужны), а также pitivi. Даже blender как-то ставил, вдруг кому интересно станет, но не прижилось. Короче эдакий ЗверьФлешка получился.

И вот теперь - представьте, я с такой сборкой хожу от супернавороченных компов, до ДОГигогерцовых старичков, на которых и хард соответственно 20/40 Гигов (для него я проблему решил просто - скачал iso с оффсайта, но все равно потом компиз и wireless отключал).

Так вот, чтоб не выделять под корень 8-10G места, считаю, что стоило бы при загрузке в режиме scratch предусмотреть установку системы не из livecd.squash монтируемго отдельно, а из /mnt/build.

В таком случае установка даже с такой флешки- Звер зоопарка происходила бы гораздо проще и быстрее:
# Заходишь в build режим, прописываешь правильные CALCULATE=“nowireless nocompiz”
# Удаляешь ВСЕ НЕНУЖНОЕ на данном компе.
# Создаешь, если необходимо нужные шаблоны
# Выходишь из build-режима. Тем временем в /mnt/build уже будет сформирована структура готовая к созданию livecd.squash либо iso-образа.
Так почему бы не установить ЭТУ САМУЮ систему прямо сейчас, минуя шаг СОЗДАНИЯ iso лишь для этого компа, а также выделив под корень не так много места, как под ПОЛНУЮ СИСТЕМУ. ( Для увеличения стабильности и отказоустойчивости, считаю, что /var/log и /var/tmp можно и нужно вынести на другую партицию, до открытия для себя LVM я это все ложил в /var/calculate/local/{log,tmp} и делал симлинк. А /tmp - вообще в tmpfs, пусть лучше мучается SWAP чем корень, в случае сбоя по питанию - пусть структура корня останется целой. Да и вообще, не стоит пользователю писать в корень, а то мало ли что еще появится)

Хотел чтоб получилось короткое предисловие, но вышло то что вышло, ИТАК - суть предложения.
Я понимаю, что сейчас идет активная работа над calculate-utilities-3, и работа над утилитами второй версии лишь отвлечет силы разработчиков.
В связи с этим предлагаю, хотя-бы в следующей версии calculate-install+calculate-builder заложить этот функциноал.
И все-же, если это не настолько сложно, прошу добавить возможность выбора установки в т.ч. из /mnt/build уже сейчас. Если грубо - там вроде лишь первый шаг поменять надо (могу ошибаться), вместо монтирования livecd.squash в SRC_DIR, bind-ом монтировать /mnt/build, а то и просто - нужной переменной задать “правильное значение”.

P.S.
На самом деле - этот вопрос волновал меня уже довольно давно. И думал я над ним тоже давно, так что возможны некоторые неточности, так что если что - не обессудьте.

В чем разница загрузиться с флешки и выполнить удаление, либо установить систему и выполнить тоже самое? От перестановки слагаемых сумма не меняется.

Еще как меняется.
Во первых - для “бюджетных” компов с одной флешки можно будет установить “бюджетную” сборку системы, а не полную, чтоб потом удалять ненужное. Тут сразу два выигрыша:
# Место под корень можно выделить меньше - считаю это порой важным плюсом для старых компов с малым хардом.
# Удаление пакетов в режие LiveCD - это просто помечание определенных файлов отсутствующими в aufs - по сути создание пустых файлов в ПАМЯТИ. Даже с учетом свопинга - по времени это меньше чем распаковка из squash-a тела файлов(чтение из образа, хоть и в ядре, но все равно ест ресурсы) и копирование на хард при инсталляции, а также удаление части только что скопированных данных с файловой системы на харде(особенно если изначально места под систему выделять впритык, зная что ненужный “хлам” будет скоро удален)
Насчет этого утверждаю опираясь на опыт хранения /var/calculate/tmp/portage в tmpfs на многих машинах, просто под SWAP выделяю достаточно. и все равно удаление распакованных данных, к примеру openoffice-а, происходит на ощутимо быстрее из tmpfs чем с харда.

Да и сам факт совмещения scratch режима с обычной установкой ИМХО - добавит уважение и любовь пользователей, особенно не гнушающихся “опытами” над своей системой - отказаться от неудачных опытов будет проще - ребут. Лишь ядро изменить/потестить наживую не получится, но и это частично обходится. Нужное включается модулем, ядро пересобирается и ручками поднимаются нужные модули, если глобально ничего не менять - то все зацепится на ура.

PS
На базе подобного способа “преднастройки набора софта” удастся реализовать схему с “разнообразным набором софта”.
К примеру с chrome/firefox/opera, wine, p2p-клиент с набор_wireless_tools и т.п.
А уж пользователь сам выберет что ему надо - ВСЕ для дома, минимальный офисный набор или офисный набор для ноутбука.
В общем все, что сейчас выключается в CALCULATE=“no…”
При чем подобные сборки пользователь сможет делать сам и под свои нужды.
Достаточно будет “запихнуть” этот весь софт в разные СЕТы и создать примитивный ГУЙ с галочками для выбора ненужных сетов и УДАЛЯТЬ НЕНУЖНЫЙ СОФТ ПЕРЕД УСТАНОВКОЙ.
Кстати, для этого можно и porthole использовать, с его механизмом отображения этих самых СЕТ-ов

Знаю, что идея СЕТ-ов уже рассматривалась ранее, и судя по всему, от нее отказались, но так и portage с set-ами вроде на месте не стоит. Надеюсь в set-ах увидеть со временем аналог(а может и частичную замену) профилям, структура и зависимости которых жестко заданны, но возможности по маскировке/размаскировке пакетов и USE ключей являются одной из ключевых особенностей системы портежей. Правда не знаю, какие планы на этот счет у gentoo-девелоперов, но надеюсь -такие-же.

Вся разница только в выполнении cl-image squash. Можно запаковку поставить gzip-ом для скорости. Сам squash при неудачном (или удачном) тестировании можно удалить. Опять таки экономится время на неудачной установке, которой не будет, т.к. образ будет протестирован. В общем неочевидные плюсы.

Сеты идут на смену не профилям, а мета-пакетам. Насколько мне известно, в будущем в них будут включена поддержка USE-флагов. Сейчас они, как ни крути, выглядят бедновато, хотя и очень удобно.

Calculate в недавних Stage-сборках начал использовать сеты:

emerge --info
...
Installed sets: @custom
...

Здесь я написал для каких целей http://www.calculate-linux.ru/blogs/ru/317/show.

Идея быстро скомпоновать образ перед установкой красивая. Но ей пока не хватает производительности портежей хотя бы на удаление. Хотя в последнее время проведены некоторые оптимизации по ускорению.

Надо будет попробовать.