Оптимизация сборки по размеру
Всех приветствую. Есть задача создать сборку определённого функционала и минимального размера. Оптимизация самого процеса компиляции не даёт желаемого выигрыша. USE-флаги тоже не всегда применимы, допустим доки не нужны, а флага doc у пакета вобще нет. Пришла мысль поработать как-то с зависимостями. Возник вопрос. Возможно ли компилить как полагается с зависимостями DEPEND, но пакеты этих зависимостей в итоговую корневую систему не включать (а включать только RDEPEND)? С Gentoo я совсем недавно работаю и отличия между этими переменными так и не нашёл - в обоих случаях происходит установка пакетов в корневую систему. А хотелось бы чтобы устанавливались только зависимости времени выполнения.
Может быть в связи с задачей у кого-то ещё есть какие-то мысли?
Заранее спасибо.
- Для комментирования войдите или зарегистрируйтесь
пробовал читать "emerge
пробовал читать "emerge --help"?
есть же куча флагов для emerge - можно собирать без зависимостей,
можно собирать, но не устанавливать...
* не устанавливать doc и пр. можно если в /etc/make.conf добавить FEATURES="noman nodoc noinfo"
Для чего это нужно?
Смотря какие цели преследуются.
Есть такой проверенный вариант.
Можно собрать Linux на базе Gentoo, но для дальнейшего внесения изменений потребуется Большой_Брат.
Вкратце алгоритм такой.
Есть хостовая машина. На ней производится сборка и хранится непорезаная версия для дальнейшей модификации.
Сборка пакетов (исключая такие как portage, gcc и тп) ведется с установленным ROOT=/куда_надо
После установки всего желаемого (ядро можно забрать из системы простым копированием) при помощи tar делается промежуточная копия, а затем она очищается от ненужных для компиляции /usr/include, и тп (по желанию в том числе и документации)
Эта сборка архивируется tar-ом и разворачивается на желаемый носитель.
Там настраивается отдельно установленный загрузчик и всё ... микроскопическая система готова
(менее 100Mб получается консольный сервер с желаемым набором ПО и возможностью за несколько минут обновить или изменить функционал)
Спасибо за ответ, таким
Спасибо за ответ, таким способом уже пробовал, при этом мусор в системе остаётся и приходится пофайлово всё вычищать, далее методом проб и ошибок проверять работоспособность (для бинарников можно ldd применить, ито она проверяет только объявленные зависимости, а если библиотека прикручивается динамически, тут придётся кучу всего перерыть). Файлы заголовков весят прилично, их естестенно убить, доки тоже складываются все в одну директорию - труда не составляет. Но хочется ещё! Пример: для компиляции могут использоваться n-библиотек, при этом для работы надо n-m, как сделать так чтобы при ROOT="mydir" emerge <пакеты> в mydir усановились только необходимые n-m а остальные использовались только на этапе компиляции.
По поводу первого ответного поста... Да доки читал, флаги они полезны, но всё равно к ответу на поставленный вопрос всё это не приводит. Может и есть какой-то хитрый ключ или способ, который поможет с минимальными усилиями скомпановать runtime зависимости без зависимостей этапа компиляции, но я его не нашёл. Тем не менее спасибо :)
собирай свой stage4 -
собирай свой stage4 - компилируешь, собираешь в бинарники (emerge --buildpkg), а затем собираешь из этих пакетов систему (emerge --usepkg)
почитай http://en.gentoo-wiki.com/wiki/Light_Install и пр.
например можно урезать дерево портеджей: http://en.gentoo-wiki.com/wiki/Tiny_Portage_Tree
Сам сейчас собираю систему,
Сам сейчас собираю систему, которую потом распространю на все используемые компьютеры. Полно ненужных зависимостей. Например, всякие *toys и *games. Ну и не используемые лично мной программы - те, которые очевидно множно не ставить. Но emerge их ставит.
Я вижу несколько путей:
1) делаем emerge, потом делаем emerge --unmerge для списка ненужного.
+ ненужные пакеты всё же удалены;
- их пришлось всё-таки скачать и собрать;
- ближайший emerge world установит всё опять.
2) делаем emerge -pv, кладём список пакетов в файл list.txt (лишние сообщения отфильтровать sed`ом). Из файла вручную выковыриваем все ненужные пакеты, а потом ставим их по порядку: for i in `cat list.txt`; do emerge --nodeps $i; done
+ не устанавливаются ненужные пакеты, не нужно скачивать;
- ближайший emerge world установит всё опять.
3) в portage-2.2, как я вычитал, есть возможность редактировать и создавать свои наборы. Я ещё не пробовал, но надеюсь, что можно будет отредактировать устанавливаемый набор с тем, чтобы не ставить лишних пакетов. А вообще, пользовательские наборы для меня давно желательная функция. Я хотел сделать набор для работы, набор для мультимедиа, набор для internet и т.д. Пока это достижимо по п.2.
По portage. Хотелось всё же иметь когда-то давно обсуждаемый USE="-games". И ещё что-то вроде /etc/portage/packages.ignore (по аналогии с /etc/portage/package.use и т.д.)
$BOC(\pi, e)$
.
В своё время успешно разрулил посредством прописывания ненужного, но требуемого по зависимостям в
/etc/portage/package.provided.Сейчас проверил и был изрядно удивлён не обнаружив этого файла в текущей версии
man portage.:wq
--
Live free or die
Да... я читал про этот файл,
Да... я читал про этот файл, но не обратил внимание - спутала фраза "Useful for porting to non-Linux systems".
Сейчас у меня portage-2.1.***, в man'e этот файл упоминатся. НО - не помогает, только что пробовал. Не понимаю, почему. Прописал всё правильно, source /etc/profile сделал. Жаль - это то, что нужно.
Нет, разобрался. В /etc/portage - не помогает (???). Но помогает, если в /etc/make.profile. И ещё момент - для пакетов нужно указывать версию - иначе ругается. Это снижает ценность данной возможности - версии постоянно обновляются.
Но в принципе, это решение моей проблемы, гораздо лучшее, чем п. 2, о котором я писал.
$BOC(\pi, e)$
Поставил portage-2.2_rc23.
Поставил portage-2.2_rc23. Там в man'е package.provided есть. Так что, наверное, прикол в том, что portage не просматривает /etc/portage на предмет поиска этого файла (??!). Остаётся редактировать /etc/make.profile/package.provided, хотя это и невелено делать. Зато помогает.
А по версиям в man'е написано: "Portage will not attempt to update a package that is listed here unless another package explicity requires a version that is newer than what has been listed". Таким образом, остаётся возможность указать нереально новую версию пакета, и он не будет обновлятся ! (наверное, буду пробовать).
Сейчас система у меня собирается "по полной" - пусть, всё уже скачано. Потом eix`ом посмотрю смысл пакетов, emerge -t - иерархию, составлю список ненужных, удалю их emerge --unmerge $i и занесу в package.provided (с большой версией, если это, конечно будет работать)
И ещё. Anarchist - спасибо большое за подсказку. Иногда читаешь доки, вроде всё понятно, а смысл не доходит. Бестолковый я, наверное, стал.
PS. "Так что, наверное, прикол в том, что portage не просматривает /etc/portage на предмет поиска этого файла (??!)" - нет, я понимаю, что в man'е /etc/portage/package.provided нет, но ведь это же и правда нелогично!
$BOC(\pi, e)$
Внимательнее читайте man
Внимательнее читайте man portage.
Файл package.provided должен быть в /etc/portage/profile/, а не в /etc/portage.
Ну да,
Ну да, да:
"/etc/portage/profile/ site specific overrides of /etc/make.profile/"
$BOC(\pi, e)$
Померяемся святостью? ;)
Дык, я говорю не про
/etc/portage/profile/(куда, ЕМНИП, ручками лезть не рекомендуют), а про/etc/portage/.В котором у меня в своё время
package.providedвполне себе работал.:wq
--
Live free or die
Anarchist Цитата:Дык, я
Anarchist
Можно ссылку кто не рекомендует туда лезть и по какой причине?
Как раз лезть в /etc/make.profile я бы не стал, т.к. этот каталог является симлинком на используемый профиль и его содержимое может измениться при emerge --sync. /etc/portage/profile в этом плане надёжнее.
Тоже припонимаю, что файл размещался раньше в /etc/portage. Видимо решили поменять местоположение, почему — не знаю...
Более поздние версии в
Более поздние версии в package.provided указывать действительно можно - работает. Конец *геймзам и *тойзам !!!
$BOC(\pi, e)$
Есть мысль, что борящимся с
Есть мысль, что борющимся с *games и *toys стоит ознакомиться с выводом
eix -p kde\*meta, а не собирать целиком KDE целиком (-:ЕТекстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.