> Как я уже сказал - я не люблю сложные bash/shell скрипты в
> принципе из-за их кривого синтаксиса.

хз, не видел ничего сложного в ебилдах. да и по большому счету туда лазить часто и не приходится.

> Как минимум читается и воспринимается легче.

отдельные IFы против тернарных операторов... хз, мне и то и другое воспринимается нормально

> Циклы я используя во внутренностях (например: найти патчи для пакета и применить
> их).

как-то сильно сложно - это ж нужно для разных версий разные патчи иметь, по именам их фильтровать? ИМХО более правильно патчи указывать явно. Явное же всегда лучше неявного.

>[оверквотинг удален]
> }
> И далее:
>

packXorg("xcb-proto"); 
> packXorg("kbproto"); 
> packXorg("inputproto"); 
> 

> И если нужно, добавляю то, что индивидуально для конкретного пакета:
>

packXorg("libXfixes"); 
>    p.dep = ["fixesproto"]; 
> 

в gentoo для этого существует eclass.

> Так выкидывать нужно на прядок больше (а то и два), чем писать
> самому. Да и что будет после апдейта? Придется постоянно отслеживать чужие
> изменения и проверять/исправлять свои для совместимости.

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

> Вы можете с ходу (за 5-60с) сказать, как именно будет собран конкретный
> пакет: какие именно команды будут выполнены? Взять тот же wine: из
> моего конфига сразу видно как он соберется. Можно ли тоже самое
> сказать ебилде wine?

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

> Как конкретно происходит развязка toolchain (binutils, gcc, glibc) от текущей системы?
> LFS собирает свой toolchain (chapter 5), затем собирает chroot и собирает
> всю систему эти toolchain. Все это прекрасно документировано и разобрано. Хотелось
> бы посмотреть, как именно организован этот процесс в gentoo и насколько
> он проще/сложнее/иначе происходит, чем в LFS?

в gentoo рекомендована установка со stage3. это готовый тарбол с toolchain и минимальным набором нужных пакетов. распаковываем, делаем в него chroot, обновляем toolchain, пересобираем всё, что есть (этот шаг в принципе можно и пропустить), затем ставим нужные пакеты.

>> отлично, а теперь всё то же самое, для всех программ, которые умеют работать с alsa
> А в чем проблема? Это указывается один раз, при первом добавлении пакета
> в систему, как и остальные опции/патчи.

дык речь идет о том, что вчера мне alsa например не нужна была, а сегодня понадобилась, и раз так - то ее нужно добавить ко всем пакетам, которые ее поддерживают. Это будет необязательно alsa, например переходим с qt4 на qt5 - пакеты не синхронно перейдут, следовательно нужно следить за изменениями и плавно переводить у себя.

>> не совсем. ментейнеры уже проверили и поправили за тебя. там, где это 100% возможно (я насчитал около 1000 пакетов, это без учета версий)
> Спасибо конечно маинтейнерам, но такого быть не может: как я уже сказал,
> я знаю только два пакета, которые не могут быть собраны статически
> - mesa и ff. Да и то раньше они умели стаитку,
> но ее сломали. Все остальные пакеты должны уметь статику.
> Так что, как я и сказал - шаг влево и правь все
> руками.

хм, я подумал, что ff и mesa как-раз можно собрать статически, а в gentoo почему-то эта возможность отсутствует.

и если взять тот же wine, то судя по всему там возможность статической линковки отсутствует - https://forum.winehq.org/viewtopic.php?t=1976
тред правда еще за 2008 год, но я так сходу больше ничего по теме не нашел. Ты можешь дать список из 10-15 пакетов, которые тебя интересуют в первую очередь?

>> не так уж много библиотек используются только одним приложением.
> Тут есть два нюанса:
> 1. Приложения должны быть одновременно запущены. У меня в системе есть gtk2,
> gtk3 и qt4 (и скоро подтянется qt5). Так вот на практике
> я редко одновременно запускаю приложения на одинаковом тулките. Что уж тут
> говорить об остальных библиотеках.

ну у меня gtk выпилен по максимуму, в основном всё на qt4 и qt5 и приложений на этих тулкитах запущено по 2-3 штуки постоянно.

> 2. Приложения должны использовать одни и те же части библиотек, что происходит
> далеко не всегда, особенно для крупных библиотек (boost/qt).

в любом случае - не думаю, что эта игра стоит свеч.

>> К тому же следить, что как используется.... увольте.
> Вообще я хочу автоматизировать процесс анализа - написать прогу, которая отследит выдаст
> какие библиотеки использовались совместно, каким количеством процессов и сколько времени
> после недели-месяца анализа.

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

>> А сколько всего пакетов то?
> ~400 в blfs. То есть в среднем 4.5 строк на пакет.

не, ну ~400 пакетов это в принципе не серъезно.

>> Я могу все эти конфиги поставить себе домой на десктоп, их же на рабочий комп, их же на рабочий сервер БД, их же на локальный NAS (Atom), их же жене на ноут и до куче матери на неттоп (тоже Atom)?
> Аналогично. Как я уже сказал у меня есть разделение на общую часть
> и индивидуальную для каждого хоста.

правильно, но при добавлении нового хоста нужно перелопатить все конфиги и внести изменения... вместо этого я поправлю /etc/make.conf (40 строк с пробелами и коментами) и возможно добавлю строчек 20 в /etc/portage/package* (и то большей частью в автоматическом режиме - мне нужно будет только принять предложенные изменения)

>> И это я еще про raspberryPi молчу, куда я тоже могу вкатить всё ту же генту со всеми теми же "конфигами".
> Кросс компиляцию и сбору под ARM я пока не встраивал. Но планы
> есть.

в gentoo это всё уже из коробки.

> Только на днях собирал новый luxrender (luxrays https://bitbucket.org/luxrender/luxrays)
> из mercurial. Он требует embree-bvh (из https://github.com/Dade916/embree#branch=bvh_build).
> У арчеводов вроде есть, а у gentoo?

в оверлеях есть практически всё
https://gpo.zugaina.org/media-gfx/luxrender

>[оверквотинг удален]
>> которые правда уже написаны и поддерживаются? Или есть какие-то вещи, которые
>> в gentoo делаются очень сложно, а в LFS - экстремально легко?
> Моя конкретная цель была создание системы которую сможет обслуживать, понимать и развивать
> один человек. Он будет знать все пакеты и опций и чем
> обоснован их выбор и как это все собирается. Он будет знать
> все патчи в своей системе и их назначение. Он не будет
> боятся что-то изменить в системе и сломать ее, так как он
> будет точно понимать что и как работает.
> Для этого нужна очень простая система, где не будет тысяч файлов со
> сборкой, а все правила будут умещаться в несколько строк.

либо второй вариант - тебе предоставили достаточно широкое пространство для маневров, и вероятность что-то сломать появляется только при выходе с этого "поля".
на данный момент я не увидел у тебя необходимость с этого поля выходить - все покрывается стандартными средствами (про статическую линковку будем говорить, когда ты ее сделаешь у себя,
я же хоть сейчас могу статически собрать всё, что точно собирается и работает)

> В целом я доволен тем, что у меня получилось. Но конечно хватает
> и слабых мест над которыми еще нужно работать.

тут гентушникам часто говорят, что не хотят тратить много времени на систему, поэтому переходят на убунту/арч
я на систему в среднем трачу до часа в месяц. боюсь даже представить, сколько у тебя времени отнимают простые операции, которые в gentoo требуют всего-лишь изменения одного USE флага