>> Потому, что в них придется разбираться и править. Как я сказал - мне нужна система идеально подогнана под мои задачи.
> дык а в чем проблема то? мне приходилось править ебилды, я даже
> доку по ним не открывал (а там были не просто опции
> сборки или патчи). Но в любом случае - один раз прочитать
> доку по ебилдам - и в путь.Как я уже сказал - я не люблю сложные bash/shell скрипты в принципе из-за их кривого синтаксиса.
> По сути, такой же
> псевдо-язык, как и в твоих примерах.
Нет. В моем случае это не псевдо язык, а полноценны язык - D, со всеми возможностями и синтаксисом близким к c/c++/java.
>[оверквотинг удален]
>> p.dep ~= ["xf86-video-intel"];
> и чем это лучше чем:
> PDEPEND="
> ...
> video_cards_i965? ( >=x11-base/xorg-server-${PV}[glamor]
> )
> video_cards_intel? ( !video_cards_i965? (
> x11-drivers/xf86-video-intel ) )
> ..."
> ??? те же яйца, только в профиль.
Как минимум читается и воспринимается легче.
>> Если нужно сделать однотипное действие для нескольких объектов (пакетов, архивов, конфигов).
> хз, мне в ебилдах циклы не попадались, да и мне как-то не
> нужны были. нужно гуглить, возможно они и есть. но в любом
> случае - пример с циклом из LFS не помешал бы, для
> понимания.
Циклы я используя во внутренностях (например: найти патчи для пакета и применить их).
Вот другой интересный пример: практически все пакеты xorg (а их очень много) собираются с одними и теми же опциями. Что бы не прописывать опции каждому пакету, я делаю так:
void packXorg(string name) {
pack(name);
p.sCfg = "./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --disable-static";
}
И далее:
packXorg("xcb-proto");
packXorg("kbproto");
packXorg("inputproto");
И если нужно, добавляю то, что индивидуально для конкретного пакета:
packXorg("libXfixes");
p.dep = ["fixesproto"];
> достаточно спорное утверждение. под свои нужды всегда можно выкинуть "лишнее" и оставить только то, что нужно именно тебе.
Так выкидывать нужно на прядок больше (а то и два), чем писать самому. Да и что будет после апдейта? Придется постоянно отслеживать чужие изменения и проверять/исправлять свои для совместимости.
> в каком месте оно теряется? открываю любой ебилд и понимаю, что там происходит. вся "магия" обычно в еклассах, но там тоже ничего сложного по большому счету нет.
Вы можете с ходу (за 5-60с) сказать, как именно будет собран конкретный пакет: какие именно команды будут выполнены? Взять тот же wine: из моего конфига сразу видно как он соберется. Можно ли тоже самое сказать ебилде wine?
> в процессе стандартного обновления - установили новый, затем обновили старый. какие детали конкретно интересуют?
Как конкретно происходит развязка toolchain (binutils, gcc, glibc) от текущей системы? LFS собирает свой toolchain (chapter 5), затем собирает chroot и собирает всю систему эти toolchain. Все это прекрасно документировано и разобрано. Хотелось бы посмотреть, как именно организован этот процесс в gentoo и насколько он проще/сложнее/иначе происходит, чем в LFS?
> отлично, а теперь всё то же самое, для всех программ, которые умеют работать с alsa
А в чем проблема? Это указывается один раз, при первом добавлении пакета в систему, как и остальные опции/патчи.
> не совсем. ментейнеры уже проверили и поправили за тебя. там, где это 100% возможно (я насчитал около 1000 пакетов, это без учета версий)
Спасибо конечно маинтейнерам, но такого быть не может: как я уже сказал, я знаю только два пакета, которые не могут быть собраны статически - mesa и ff. Да и то раньше они умели стаитку, но ее сломали. Все остальные пакеты должны уметь статику.
Так что, как я и сказал - шаг влево и правь все руками.
> не так уж много библиотек используются только одним приложением.
Тут есть два нюанса:
1. Приложения должны быть одновременно запущены. У меня в системе есть gtk2, gtk3 и qt4 (и скоро подтянется qt5). Так вот на практике я редко одновременно запускаю приложения на одинаковом тулките. Что уж тут говорить об остальных библиотеках.
2. Приложения должны использовать одни и те же части библиотек, что происходит далеко не всегда, особенно для крупных библиотек (boost/qt).
> К тому же следить, что как используется.... увольте.
Вообще я хочу автоматизировать процесс анализа - написать прогу, которая отследит выдаст какие библиотеки использовались совместно, каким количеством процессов и сколько времени после недели-месяца анализа.
> А сколько всего пакетов то?
~400 в blfs. То есть в среднем 4.5 строк на пакет.
> Я могу все эти конфиги поставить себе домой на десктоп, их же на рабочий комп, их же на рабочий сервер БД, их же на локальный NAS (Atom), их же жене на ноут и до куче матери на неттоп (тоже Atom)?
Аналогично. Как я уже сказал у меня есть разделение на общую часть и индивидуальную для каждого хоста.
> И это я еще про raspberryPi молчу, куда я тоже могу вкатить всё ту же генту со всеми теми же "конфигами".
Кросс компиляцию и сбору под ARM я пока не встраивал. Но планы есть.
> И да, соберу я на каждом из этих устройств абсолютно разные системы, т.к. требования везде разные.
Аналогично.
> Другое дело, что я уже давно не
> встречал пакетов, ебилдов для которых нет в оверлеях.
Только на днях собирал новый luxrender (luxrays https://bitbucket.org/luxrender/luxrays) из mercurial. Он требует embree-bvh (из https://github.com/Dade916/embree#branch=bvh_build). У арчеводов вроде есть, а у gentoo?
> Итак, насколько я понимаю - все претензии к gentoo - "жирность" ебилдов,
> которые правда уже написаны и поддерживаются? Или есть какие-то вещи, которые
> в gentoo делаются очень сложно, а в LFS - экстремально легко?
Моя конкретная цель была создание системы которую сможет обслуживать, понимать и развивать один человек. Он будет знать все пакеты и опций и чем обоснован их выбор и как это все собирается. Он будет знать все патчи в своей системе и их назначение. Он не будет боятся что-то изменить в системе и сломать ее, так как он будет точно понимать что и как работает.
Для этого нужна очень простая система, где не будет тысяч файлов со сборкой, а все правила будут умещаться в несколько строк.
В целом я доволен тем, что у меня получилось. Но конечно хватает и слабых мест над которыми еще нужно работать.
