Сформированы (http://lists.linuxfromscratch.org/pipermail/lfs-support/2017...) новые выпуски руководств Linux From Scratch 8.0 (http://www.linuxfromscratch.org/lfs/view/8.0/) (LFS) и Beyond Linux From Scratch 8.0 (http://www.linuxfromscratch.org/blfs/view/8.0) (BLFS), а также редакций LFS и BLFS с системным менеджером systemd. В Linux From Scratch приведены инструкции по созданию с нуля базовой Linux-системы, используя лишь исходные тексты необходимого программного обеспечения. Beyond Linux From Scratch дополняет инструкции LFS информацией о сборке и настройке около 800 программных пакетов, охватывающих различные области применения, от СУБД и серверных систем, до графических оболочек и медиапроигрывателей.В Linux From Scratch 8.0 произведено (http://linuxfromscratch.org/lfs/view/8.0/chapter01/whatsnew....) обновление 29 пакетов, исправлены ошибки в загрузочных скриптах, выполнены редакторские работы в пояснительных материалах по всей книге. В новой версии осуществлён переход на ядро Linux 4.9, обновлены
glibc 2.24, binutils 2.27, gcc 6.2.0, Bash 4.4, Perl 5.24.1,
Util-Linux 2.29.1, Vim 8. В Beyond Linux From Scratch 7.10 по сравнению с прошлым выпуском отмечено 775 обновлений программ, среди которых KDE Plasma 5.9, KDE Applications 16.12 и GNOME 3.22.
Переход к новой ветке 8.0 обусловлен удалением символической ссылки с /lib на /lib64, прекращением использования отдельной директории /usr/lib64 и включением нового компоновщика /usr/bin/ld.gold, который пока не задействован по умолчанию.Кроме LFS и BLFS в рамках проекта выпускалось несколько дополнительных книг:
- "Automated Linux From Scratch (http://www.linuxfromscratch.org/alfs/)" - фреймворк для автоматизации сборки LFS-системы и управлению пакетами;- "Cross Linux From Scratch (http://clfs.org/)" - описание кроссплатформенной сборки LFS-системы, поддерживаются архитектуры: x86, x86_64, sparc, mips, PowerPC, alpha, hppa, arm;
- "Hardened Linux From Scratch (http://www.linuxfromscratch.org/hlfs/)" - инструкции по повышению безопасности LFS, применению дополнительных патчей и ограничений;
- "LFS Hints (http://www.linuxfromscratch.org/hints/)" - подборка дополнительных советов с описанием альтернативных решений для описанных в LFS и BLFS шагов;
- "LFS LiveCD (http://www.linuxfromscratch.org/livecd/)" - проект по подготовке LiveCD. На данный момент не развивается.
URL: http://lists.linuxfromscratch.org/pipermail/lfs-support/2017...
Новость: https://www.opennet.ru/opennews/art.shtml?num=46106
Господа, кто пользуется (неважно дома или продакшн сервер), расскажите как оно? Или это все таки на раз поиграться?
> Господа, кто пользуется (неважно дома или продакшн сервер), расскажите как оно?как соберёшь и как настроишь )
Это, скорее всего, для всяких эмбедщиков, которым нужна маленькая система заточенная под конкретную железяку. На кой чёрт это "дома или продакшн сервер"?
Нет. Для эмбедщиков - билдрут, опенэмбеддед, йокто.Если вы в свою эмбеддовку можете засенуть лфс, то проще будет взять чентозь или убунту.
Если вы в свою эмбеддовку не можете засунуть даже билдрут, то переходим на фриртос. Остальное - от лукавого.
генту тоже ок
> генту тоже окНе совсем, и не всегда. Так же, как и любое другое решение.
Гента по составу, так же как и лфс, близка к десктопу и серверу, а не к эмбеддовке. Если ваше железо позволяет, то см выше...
> Не совсем, и не всегда.А можно пример, когда гента не подходит? Учитывая что ее ebuild'ы - это bash скрипты, которые делают wget, gunzip, configure, make, make install...
Как по мне, гента - тот же LFS, но за тебя уже сделали всю рутинную работу: скачивание, распаковка, зависимости и т. п. При этом тебе оставили всю гибкость LFS, так как ты можешь легко вмешаться в любой этап процесса.
LFS - 1) для целей обучения и 2) если ты и впрямь решил запилить свой собственный дистр, притом не-Gentoo-based - тогда да, проще переписать скрипты самому, а не разбираться в существующих.
Там товарищ А.Шатал про эмбеддовку тред начал. А полновесный дистрибутив линуха(*бунта, чентозь, гента, лфс) - это не то, что нужно в эмбеддовке. Там нужны дистры на бизибоксе и мюслях. Alpine, да и тот с натяжкой пойдёт. Намного удобнее здесь будут: openwrt, clfs, yosto, openembedded, buildroot. А возможность в генте и лфс выоптимизировать эти несколько процентов производительности или места - мало что значит. Говорю, как гентушник и лфсник.
> Намного удобнее здесь будут: openwrt, clfs, yosto, openembedded, buildroot.Это понятно, что есть специализированные дистры, и нужно использовать их, если нет уж слишком специфичных требований. Но мы ведь и говорим именно про специфичные требования, под которые гипететически openwrt, clfs, yosto, openembedded, buildroot не подходят, не так ли? Или какой контекст использования LFS?
> Там нужны дистры на бизибоксе и мюслях.
http://gpo.zugaina.org/sys-apps/busybox
http://mirror.yandex.ru/gentoo-distfiles/releases/amd64/auto...
Я уже молчу, что можно начать не со stage3Мой кey message: если жизнь свела с такой задачей, что ни один даже специализированный дистр с ней не справляется, то Gentoo очень даже неплохая альтернатива LFS.
Если не согласен - приведи конкретный пример чего в Генте сделать нельзя.
> Если вы в свою эмбеддовку можете засенуть лфс, то проще будет взять
> чентозь или убунту.LFS это только книга рекомендаций, а не свод законов. Вы вполне можете выкинуть/заменить лишнее.
Например проигнорировать её полностью. Только это уже не будет лфс.
А вот в качестве учебника - да, это лучший вариант.
Скорее обучалка юнных линуксоидов, собрав разок появляется понимание, где закачивается дистрибутив конкретной софтины и начинается дистрибутив ОС.
Постоянно пользоваться lfs имеет смысл, если хотите создать собственную уникальную систему, под свои индивидуальные требования. Да и то, как ветеран lfs (использую с 2001г), могу сказать, что сейчас мне интересны только изменения в сборке toolchain (+ иногда заглядываю в wiki arch linux и gentoo).В общем lfs дает знание о том, с чего начинается сборка системы, а как использоваться эти знания дальше решать вам.
Для мене лично нравится полностью понимать свою систему и контролировать ее работу. Вся сборка автоматизированна - на выходе получается полностью настроенная и пропатченная система под мои требования и задачи. Для меня это быстрее и проще, чем модифицировать чужой дистрибутив и разбираться с чужими нововведениям при каждом серьезном обновлении.
> уникальные требованиеМожно пример хоть одного уникального требования?
> Можно пример хоть одного уникального требования?Мои личные:
1. Легковесная система в плане потребления ресурсов - без systemd/pa/dbus/etc, замена разжиревших частей на легковесные (busybox, pkgconf, charfbuzz, etc). Только реально используемые пакеты, собранные с отключенными неиспользуемыми мной опциями.
2. Простая для понимания, настройки и модификации система (что частично получается автоматом из пункта 1). Тоже касается системы сборки.
3. Возможность автоматической пересборки всей системы (при смене версии компилятора или его опций). На выходе должна получаться система полностью идентичная текущей (пакеты, патчи, настройки).
чет не увидел преимуществ перед gentoo... она все эти требования покрывает
А кто-то говорил, что есть какие-то преимущества?
дык недостатки же очевидны, значит должны быть либо преимущества, либо требования, которые не покрывает решение, лишенное этих недостатков.
> чет не увидел преимуществ перед gentoo... она все эти требования покрываетНе могу перечислить все недостатки gentoo, так как пробовал ее очень давно.
Но лично для меня не приемлема система сборки на bash скриптах.
Я использую скрипты для линейного кода (запуска подряд) или соединения нескольких команд через pipe. Но если нужны условия, циклы или что-то еще - предпочитаю полноценные ЯП.Сами же ebuild раздуты неимоверно, так как пытаются покрыть все платформы и все случаи.
Вот пример для wine:
https://github.com/mradermaxlol/maxik-overlay/blob/master/ap...Вот пример из моей системы:
pack("wine");
p.dep = ["xorg", "flex", "bison"];
p.env["CFLAGS"] = cflags.except("-O3"); //fix "wine: could not load kernel32.dll, status c000007b" on wine startup
p.sCfg = "./configure --prefix=/usr --disable-win16 --disable-tests --without-oss --without-freetype";
p.sInstall = "make install && rm -f /usr/share/wine/fonts/tahoma*";Также я не вполне уверен, насколько легко можно сделать что-то выходящие за заранее определенные USE флаги. К примеру я хочу в ближайшем времени построить систему, где все библиотеки (за исключением 5-20 часто используемых) будут статическими и соответственно все приложения тоже. Насколько легко это решается в gentoo?
какая тебе разница, что там в ебилдах и на чем они написаны?Там кстати не совсем баш: https://wiki.gentoo.org/wiki/Ebuild
An ebuild file is a text file, used by Gentoo package managers, which identify a specific software package and how the Gentoo package manager should handle it. It uses a bash-like syntax style and is standardized through the EAPI version.
В твоем примере я не увидел ни условий, ни циклов. В ебилдах я правда тоже не припомню циклы (зачем они там?), а вот условий там хватает. Да, задача ебилда - покрыть максимально возможное количество вариантов использования. В каком месте это недостаток? NIH-синдром?
Взять тот же вайн. Что нужно сделать, чтобы в твоем примере добавить поддержку alsa и vaapi ? Добавить опции в configure мало, нужно еще и зависимости собрать, а там тоже есть нюансы... И мне не совсем понятно, где в твоем примере патчи (которые нужно применять в зависимости от условий).
По поводу static - есть USE-флаг. Да, он есть далеко не у всех пакетов. Но ты и не забывай, что далекое не всё можно статически слинковать. Да и не совсем понятно, зачем это нужно - память девать некуда?
А выйти за рамки "заранее определенных" USE-флагов легко. Нет никаких "заранее определенных" - каждый ebuild описывает те флаги, которые он использует и может добавлять те, которых нет ни в одном другом ebuild. Поэтому если тебе нужно - копируешь ebuild в локальный репозиторий и делаешь там с ним всё, что тебе хочется (хоть с нуля переписывай, если тебя вообще всё не устраивает)
> какая тебе разница, что там в ебилдах и на чем они написаны?Потому, что в них придется разбираться и править. Как я сказал - мне нужна система идеально подогнана под мои задачи.
> В твоем примере я не увидел ни условий,
packMeta("xorg");
p.dep = ["xf86-input-keyboard", "xkeyboard-config", "xf86-input-mouse", "fonts", "xset", "xsetroot", "xmodmap", "xlsfonts"];
if (video == "i915")
p.dep ~= ["xf86-video-intel"];
if (video == "radeon")
p.dep ~= ["xf86-video-ati"];
if (video == "fglrx")
p.dep ~= ["amd-catalyst"];> ни циклов. В ебилдах я правда тоже не припомню циклы (зачем они там?),
Если нужно сделать однотипное действие для нескольких объектов (пакетов, архивов, конфигов).
> Да, задача ебилда - покрыть максимально возможное количество
> вариантов использования. В каком месте это недостаток?Сложнее и дольше модифицировать под свои нужды. Теряется прозрачность и понимание работы системы. Да и сама система абстрагирования от опций через USE флаги мне не нравится: для каждого пакета нужно описывать все опции вместо того, что бы напрямую их указать.
На phoronix (https://www.phoronix.com/forums/forum/phoronix/latest-phoron...) правду говорят, что gentoo до сих пор привязан к gcc-4.9.4? Как у gentoo вообще toolchain собирается/обновляется? Что нужно сделать, чтобы пресобрать систему с другой стандартной библиотекой C (musl)?
> Взять тот же вайн. Что нужно сделать, чтобы в твоем примере добавить
> поддержку alsa-p.dep = ["xorg", "flex", "bison"];
+p.dep = ["xorg", "flex", "bison", "alsa-lib"];> И мне не совсем понятно, где в твоем примере патчи (которые нужно применять
> в зависимости от условий).Патчи (как и исходники и конфиги) хранятся либо в общей директории для всех сборок, либо в директории конкретной сборки. Сперва применяются патчи из общей директории, затем из специфичной для сборки. При необходимости можно вообще отключить автоматическое наложение патчей и прописать все вручную (с условиями или без).
> По поводу static - есть USE-флаг. Да, он есть далеко не у
> всех пакетов.Вот и я о том же. Все равно все руками править и перепроверять.
> Но ты и не забывай, что далекое не всё
> можно статически слинковать.Из распространенного - mesa и ff. Или что-то забыл?
> Да и не совсем понятно, зачем это нужно
> - память девать некуда?Наоборот - если библиотека используется только одним приложением, то статика выгоднее.
https://www.linux.org.ru/news/opensource/12463464/page5#comm...
https://www.linux.org.ru/news/opensource/12463464/page6#comm...> А выйти за рамки "заранее определенных" USE-флагов легко. Нет никаких "заранее определенных"
> - каждый ebuild описывает те флаги, которые он использует и может
> добавлять те, которых нет ни в одном другом ebuild. Поэтому если
> тебе нужно - копируешь ebuild в локальный репозиторий и делаешь там
> с ним всё, что тебе хочется (хоть с нуля переписывай, если
> тебя вообще всё не устраивает)У меня все конфиги сборки пакетов - ~800 строк lfs + ~1800 blfs. Что проще по-вашему править?
Если пакет собирается через ./configure --prefix=/usr && make && make install, я просто добавляю одну строку в конфиг (и + одну если есть зависимости):
pack("gtkperf");
p.dep = ["gtk+"];
> Потому, что в них придется разбираться и править. Как я сказал - мне нужна система идеально подогнана под мои задачи.дык а в чем проблема то? мне приходилось править ебилды, я даже доку по ним не открывал (а там были не просто опции сборки или патчи). Но в любом случае - один раз прочитать доку по ебилдам - и в путь. По сути, такой же псевдо-язык, как и в твоих примерах.
> if (video == "i915")
> 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 не помешал бы, для понимания.
> Сложнее и дольше модифицировать под свои нужды.
достаточно спорное утверждение. под свои нужды всегда можно выкинуть "лишнее" и оставить только то, что нужно именно тебе.
> Теряется прозрачность и понимание работы системы.
в каком месте оно теряется? открываю любой ебилд и понимаю, что там происходит. вся "магия" обычно в еклассах, но там тоже ничего сложного по большому счету нет.
> Да и сама система абстрагирования от опций через USE флаги мне не нравится: для каждого пакета нужно описывать все опции вместо того, что бы напрямую их указать.не нужно всё описывать для каждого пакета. есть глобальные настройки USE-флагов (большинство из них - в профиле), но ты можешь переопределить как глобальные, так и "локальные", для конкретного пакета. Где тут "непрямое указание"? Если тебе нужно для конкретного пакета включить или выключить конкретный USE флаг - ты это делаешь, не трогая остальные, которые остаются в соответствии с остальными настройками.
> На phoronix (https://www.phoronix.com/forums/forum/phoronix/latest-phoron...) правду говорят, что gentoo до сих пор привязан к gcc-4.9.4?привязан - сильно сказано. на сегодня именно эта версия отмечена разработчиками как последняя стабильная. К установке доступны 5.3 и 5.4, но они помечены как нестабильные - это значит, что в каких-то пакетах есть проблемы с этой версией компилятора. Так же доступна версия 6.3.0, но она "замаскирована", т.е. хочешь - ставь - но всё на твой страх и риск, тебя предупредили.
> Как у gentoo вообще toolchain собирается/обновляется?
в процессе стандартного обновления - установили новый, затем обновили старый. какие детали конкретно интересуют?
> Что нужно сделать, чтобы пресобрать систему с другой стандартной библиотекой C (musl)?
если вкратце - подключить оверлей, сменить профиль и пересобрать @world (с -e для надежности - пересоберется вообще всё)
> -p.dep = ["xorg", "flex", "bison"];
> +p.dep = ["xorg", "flex", "bison", "alsa-lib"];отлично, а теперь всё то же самое, для всех программ, которые умеют работать с alsa
> Вот и я о том же. Все равно все руками править и перепроверять.не совсем. ментейнеры уже проверили и поправили за тебя. там, где это 100% возможно (я насчитал около 1000 пакетов, это без учета версий) - ты можешь это сделать обычным USE флагом.
> Из распространенного - mesa и ff. Или что-то забыл?
я ж не знаю, что тебе нужно. я вообще статической линковкой не увлекаюсь.
mesa и ff- на данный момент ебилды в офф. дереве не поддерживают static. Но добавить это - задача на 5 минут. Другое дело - не факт, что не потребуется доработки каких-то других ебилдов... поэтому возможно задача затянется. Но я тут не вижу никаких потенциальных преимуществ у LFS. В gentoo ты просто копируешь нужные тебе ебилды в локальный оверлей, правишь их - и всё.> Наоборот - если библиотека используется только одним приложением, то статика выгоднее.
не так уж много библиотек используются только одним приложением. К тому же следить, что как используется.... увольте.
> У меня все конфиги сборки пакетов - ~800 строк lfs + ~1800 blfs. Что проще по-вашему править?
А сколько всего пакетов то? Я могу все эти конфиги поставить себе домой на десктоп, их же на рабочий комп, их же на рабочий сервер БД, их же на локальный NAS (Atom), их же жене на ноут и до куче матери на неттоп (тоже Atom)? И это я еще про raspberryPi молчу, куда я тоже могу вкатить всё ту же генту со всеми теми же "конфигами". И да, соберу я на каждом из этих устройств абсолютно разные системы, т.к. требования везде разные.
> Если пакет собирается через ./configure --prefix=/usr && make && make install, я просто добавляю одну строку в конфиг (и + одну если есть зависимости):
соглашусь, ебилд будет несколько "жирнее". Другое дело, что я уже давно не встречал пакетов, ебилдов для которых нет в оверлеях.
Итак, насколько я понимаю - все претензии к gentoo - "жирность" ебилдов, которые правда уже написаны и поддерживаются? Или есть какие-то вещи, которые в gentoo делаются очень сложно, а в LFS - экстремально легко?
>> Потому, что в них придется разбираться и править. Как я сказал - мне нужна система идеально подогнана под мои задачи.
> дык а в чем проблема то? мне приходилось править ебилды, я даже
> доку по ним не открывал (а там были не просто опции
> сборки или патчи). Но в любом случае - один раз прочитать
> доку по ебилдам - и в путь.Как я уже сказал - я не люблю сложные 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 - экстремально легко?Моя конкретная цель была создание системы которую сможет обслуживать, понимать и развивать один человек. Он будет знать все пакеты и опций и чем обоснован их выбор и как это все собирается. Он будет знать все патчи в своей системе и их назначение. Он не будет боятся что-то изменить в системе и сломать ее, так как он будет точно понимать что и как работает.
Для этого нужна очень простая система, где не будет тысяч файлов со сборкой, а все правила будут умещаться в несколько строк.
В целом я доволен тем, что у меня получилось. Но конечно хватает и слабых мест над которыми еще нужно работать.
> Как я уже сказал - я не люблю сложные bash/shell скрипты в
> принципе из-за их кривого синтаксиса.хз, не видел ничего сложного в ебилдах. да и по большому счету туда лазить часто и не приходится.
> Как минимум читается и воспринимается легче.
отдельные IFы против тернарных операторов... хз, мне и то и другое воспринимается нормально
> Циклы я используя во внутренностях (например: найти патчи для пакета и применить
> их).как-то сильно сложно - это ж нужно для разных версий разные патчи иметь, по именам их фильтровать? ИМХО более правильно патчи указывать явно. Явное же всегда лучше неявного.
>[оверквотинг удален]
> }
packXorg("xcb-proto"); packXorg("libXfixes"); в 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 флага
> как-то сильно сложно - это ж нужно для разных версий разные патчи
> иметь, по именам их фильтровать?Да, но что в этом сложного?
Вот пример из моей системы:gtk+-Add_paste_selection_keybind_signal.patch
gtk+-INSENSITIVE_without_shadow.patch
gtk+-notebook_tab_height_uniform.patch
gtk+-single_click.patch
gtk+3-without_atk_bridge.patch> ИМХО более правильно патчи указывать явно.
> Явное же всегда лучше неявного.По-моему это дублирование работы - сперва залить все нужные патчи в нужную директорию, а затем прописывать их вручную. Да и удобнее смотреть именно файлы - их можно выбрать по маске или сразу посмотреть что в них внутри ( а там часто бывает подробное описание).
>> Вы можете с ходу (за 5-60с) сказать, как именно будет собран конкретный
>> пакет: какие именно команды будут выполнены? Взять тот же wine: из
>> моего конфига сразу видно как он соберется. Можно ли тоже самое
>> сказать ебилде wine?
> полный конечный список команд выдать не смогу конечно, т.к. как минимум нужно
> проверить, какие USE флаги включены. вот только я не понимаю, зачем
> мне эта информация.Что бы быстро понять, что происходит и как изменить поведение на желаемое.
> Если оно собирается и работает - хорошо. Нет
> - начинаю разбираться. И в процессе разбора список команд меня будет
> интересовать в последнюю очередь. Хотя я уже и не вспомню, когда
> у меня в стабильной ветке что-то не собиралось или не запускалось.Да, но с такой позиции - зачем вообще что-то собирать? Можно взять готовый бинарный дистрибутив - там просто все работает.
Меня интересует система идеально подогнанная под меня. Это значит что 50% пакетов будут собраны с опциями отличными от тех, что по-умолчанию. А если мне придется еще и все мои патчи/хаки прописывать - то получится все 80-90%.
>> Как конкретно происходит развязка toolchain (binutils, gcc, glibc) от текущей системы?
>> LFS собирает свой toolchain (chapter 5), затем собирает chroot и собирает
>> всю систему эти toolchain. Все это прекрасно документировано и разобрано. Хотелось
>> бы посмотреть, как именно организован этот процесс в gentoo и насколько
>> он проще/сложнее/иначе происходит, чем в LFS?
> в gentoo рекомендована установка со stage3. это готовый тарбол с toolchain и
> минимальным набором нужных пакетов. распаковываем, делаем в него chroot, обновляем toolchain,
> пересобираем всё, что есть (этот шаг в принципе можно и пропустить),
> затем ставим нужные пакеты.Меня интересует как именно происходит сборка gcc самим gcc в gentoo. Для того чтобы отвязаться от хоста (или от перекомпилированного toolchain). Могу я без проблем получить gcc-6.3.0 собранный gcc-6.3.0 как в lfs? Там для этого процесс сборки gcc идет в три этапа.
> дык речь идет о том, что вчера мне alsa например не нужна
> была, а сегодня понадобилась, и раз так - то ее нужно
> добавить ко всем пакетам, которые ее поддерживают.Ну будет 5-10 исправлений. Это ведь личная система, а не debian на 30000 пакетов.
> Это будет необязательно alsa,
> например переходим с qt4 на qt5 - пакеты не синхронно перейдут,
> следовательно нужно следить за изменениями и плавно переводить у себя.Естественно. Более того, многие порты мне не нравятся и я принципиально оставляю их на старом тулките, пока новый порт до ума не доведут.
> и если взять тот же wine, то судя по всему там возможность
> статической линковки отсутствует - https://forum.winehq.org/viewtopic.php?t=1976Вполне возможно. Wine весьма специфическая штука - ОС внутри ОС.
> тред правда еще за 2008 год, но я так сходу больше ничего
> по теме не нашел. Ты можешь дать список из 10-15 пакетов,
> которые тебя интересуют в первую очередь?Все подряд. Проще сказать, что не интересует - glibc, glib, freetype, zlib, ну может 5-10 наберется.
> в любом случае - не думаю, что эта игра стоит свеч.
Нужно проверять на практике. Все долго и упорно кричали как здорово разделяемые библиотеки экономят память, а на практике оказалось - единицы процентов, да и то не всегда. Зато dll hell пришел и на линуксы.
> вот это интересно было бы посмотреть. тогда и можно будет говорить о
> том, насколько статическая линковка полезна в каждом конкретном случае.Ну если руки дойдут проверить - напишу небольшую статью по этому поводу.
>>> А сколько всего пакетов то?
>> ~400 в blfs. То есть в среднем 4.5 строк на пакет.
> не, ну ~400 пакетов это в принципе не серъезно.Обоснуйте. У меня это десктоп/ноутбук. Круг задач - программирование (c, c++, d) + кросскомпиляторы для ARM и AVR, работа с 2d и 3d графикой, работа со звуком, работа с видео, ну и стандартные - браузер, офис и прочее. Все (ну почти все, при большом желании всегда есть что выпилить :) бесполезные для меня зависимости отключены.
> правильно, но при добавлении нового хоста нужно перелопатить все конфиги и внести
> изменения...Нет. Для нового нужно:
switch (hostName) {
case "egoOne":
makeflags = "-j4";
video = "radeon";
// optimize = "fast";
optimize = "release";
// optimize = "debug";
// optimize = "none";
break;
case "KS":
makeflags = "-j3";
optimize = "release";
video = "i915";
break;
+ case "newHost":
+ makeflags = "-j3";
+ optimize = "release";
+ video = "nv";
+ break;Остальные изменения - только новое, специфичное для хоста. Если это только патчи - то вообще ничего менять не нужно - просто положить патчи в директорию с названием хоста.
> в оверлеях есть практически всё
> https://gpo.zugaina.org/media-gfx/luxrenderМягко говоря - очень печально. Последняя стабильная - 1.3 да и та rc1, хотя давно уже вышел 1.6. Правила сборки текущего среза тоже устарели почти на года. Зависимость должна быть не от embree, а от embree-bvh с github.
Надеюсь это редкое исключение, а не общая тенденция.
> либо второй вариант - тебе предоставили достаточно широкое пространство для маневров, и
> вероятность что-то сломать появляется только при выходе с этого "поля".
> на данный момент я не увидел у тебя необходимость с этого поля
> выходить - все покрывается стандартными средствамиМожно, только перелопачивать на порядок-два больше, что бы сделать точно тоже самое что у меня сейчас. И дальше больше мучится с сопровождением.
> я на систему в среднем трачу до часа в месяц. боюсь даже
> представить, сколько у тебя времени отнимают простые операции, которые в gentoo
> требуют всего-лишь изменения одного USE флагаЗависит от того, что нужно. Обновить софтину - скачал пакет и написал оду команду. Больше отнимает времени софт сильно модифицированный патчами. Но использовать его без патчей я не могу (даже жена плюется, когда ей приходится использовать на работе под виндой немодифицированные версии :), а нормально полноценно исправить - руки не доходят, так как изменения нетривиальны, да и не уверен я что их действительно включат - всем не угодишь.
Мелкие патчи естественно стараюсь побыстрее в upsteream отправить.
Бывают вообще курьезные случаи - в gtk3 была возможность собирать без atk-bridge, который мне не нужен от слова совсем. Затем какой-то умник сделал его mandatory. Его спрашивают - нахуа? А он - меньше вариантов сборки - проще тестировать. Если бы он увидел "make menuconfig" busybox или ядра, его бы наверно инсульт хватил :) И что в итоге? Откатил я его изменения в 2013 году и до сих пор gtk3 собирается и работает без проблем без этого atk-bridge все с тем же патчем 2013 года. А потом все удивляются, почему в дистрибутиве минимуму 100500 пакетов для обычного десктопа ...
Бывает конечно, что есть настроение и начинаешь экспериментировать с системой (типа как идея со смешанной линковкой), но это от перфекционизма в клинической стадии :)
> Да, но что в этом сложного?
> Вот пример из моей системы:
> gtk+-Add_paste_selection_keybind_signal.patch
> gtk+-INSENSITIVE_without_shadow.patch
> gtk+-notebook_tab_height_uniform.patch
> gtk+-single_click.patch
> gtk+3-without_atk_bridge.patchгде гарантия, что ни один патч не сломается при следующем минорном апдейте? И если мне нужно держать несколько версий одного пакета, с разными патчами - тогда как?
Далее - некоторые патчи должны быть применены только при указании какой-то конкретной зависимости. В итоге - в цикле проверяем имя патча, версию пакета, зависимости... как-то не сильно рационально... Хотя это конечно уже детали реализации, сделать нормально LFS насколько я понял позволяет.
> По-моему это дублирование работы - сперва залить все нужные патчи в нужную директорию, а затем прописывать их вручную. Да и удобнее смотреть именно файлы - их можно выбрать по маске или сразу посмотреть что в них внутри ( а там часто бывает подробное описание).
дык обновление пакета - это в любом случае работа. и смотреть будешь именно на файлы, только как минимум сгруппированные по пакету.
> Что бы быстро понять, что происходит и как изменить поведение на желаемое.
тут 2 основных варианта - либо включить/отключить USE флаг, либо включить/отключить патч. У меня такое редко занимает дольше минуты вне зависимости от сложности ебилда.
> Да, но с такой позиции - зачем вообще что-то собирать? Можно взять готовый бинарный дистрибутив - там просто все работает.
в бинарном дистрибутиве нет возможности добавить/убрать зависимость. точнее какбэ есть, но это долго и муторно.
> Меня интересует система идеально подогнанная под меня. Это значит что 50% пакетов будут собраны с опциями отличными от тех, что по-умолчанию. А если мне придется еще и все мои патчи/хаки прописывать - то получится все 80-90%.
Наборы USE-флагов уникальны в каждой установке gentoo и подогнаны под конкретные требования.
С патчами все более-менее равномерно, но добавить свой патч - дело пары минут (естественно кроме времени написания это патча)> Меня интересует как именно происходит сборка gcc самим gcc в gentoo. Для того чтобы отвязаться от хоста (или от перекомпилированного toolchain). Могу я без проблем получить gcc-6.3.0 собранный gcc-6.3.0 как в lfs? Там для этого процесс сборки gcc идет в три этапа.
Да, без проблем. Выглядит это примерно так:
emerge -avuq gcc //обновляем gcc
gcc-config -l //смотрим список установленных gcc
gcc-config 1 //переключаемся на нужный gcc
emerge -vq gcc //пересобираем gcc выбранной версией> Ну будет 5-10 исправлений. Это ведь личная система, а не debian на 30000 пакетов.
меня больше интересует процесс определения пакетов, в которые можно внести эти изменения
> Все подряд. Проще сказать, что не интересует - glibc, glib, freetype, zlib, ну может 5-10 наберется.
как мы уже выяснили на примере wine - далеко не всегда статическая линковка возможна. поэтому я тебе сейчас не готов сказать, для каких пакетов она возможна, но не поддерживается в gentoo из коробки.
> Нужно проверять на практике. Все долго и упорно кричали как здорово разделяемые библиотеки экономят память, а на практике оказалось - единицы процентов, да и то не всегда. Зато dll hell пришел и на линуксы.ну с dll hell ты конечно перегнул... в общем, спорить на эту тему у меня нет желания - слишком мало вводных данных. Когда/если ты таки решишься собрать статикой по максимуму - надеюсь будут конкретные цифры, которые можно будет обсудить.
> Обоснуйте. У меня это десктоп/ноутбук. Круг задач - программирование (c, c++, d) + кросскомпиляторы для ARM и AVR, работа с 2d и 3d графикой, работа со звуком, работа с видео, ну и стандартные - браузер, офис и прочее. Все (ну почти все, при большом желании всегда есть что выпилить :) бесполезные для меня зависимости отключены.
вопрос в трудозатратах на добавление нового пакета. я теперь начинаю понимать, почему тебе нравится система с ~4.5 строчками на новый пакет. Ты не учитываешь тот нюанс, что ебилды постоянно для этого писать не приходится - под основную массу софта уже всё есть. В моем примере - у меня на работе и дома круг задач несколько различается. Если взять ноут жены и неттоп матери - там отличия от моих систем кардинальные. плюс к этому домашняя файлопомойка со своими требованиями/задачами... честно, я хз, сколько времени мне бы пришлось тратить на этот очень небольшой зоопарк в случае использования LFS. При этом преимуществ я до сих пор не вижу.
> Остальные изменения - только новое, специфичное для хоста. Если это только патчи - то вообще ничего менять не нужно - просто положить патчи в директорию с названием хоста.
как минимум - наборы зависимостей для многих пакетов на моих системах достаточно сильно различаются.
> Мягко говоря - очень печально. Последняя стабильная - 1.3 да и та rc1, хотя давно уже вышел 1.6. Правила сборки текущего среза тоже устарели почти на года. Зависимость должна быть не от embree, а от embree-bvh с github.
да, посмотрел - там последний ебилд за 2015 год. Видимо, не очень популярный пакет среди гентушников.
> Надеюсь это редкое исключение, а не общая тенденция.
нужно смотреть по конкретному софту. как по мне - репозиторий генты - самый полный из известных мне дистрибутивов. плюс к этому - достаточно несложная процедура добавления нужных лично тебе пакетов. Тягаться тут может только арч (с AUR). Но мне этот дистрибутив жутко не нравится.
> Можно, только перелопачивать на порядок-два больше, что бы сделать точно тоже самое что у меня сейчас. И дальше больше мучится с сопровождением.
дык а что у тебя сделано такое уникальное то? я вот смотрю на куски твоих конфигов - все решается добавлением/удалением USE флагов.
>Зависит от того, что нужно. Обновить софтину - скачал пакет и написал оду команду. Больше отнимает времени софт сильно модифицированный патчами. Но использовать его без патчей я не могу (даже жена плюется, когда ей приходится использовать на работе под виндой немодифицированные версии :), а нормально полноценно исправить - руки не доходят, так как изменения нетривиальны, да и не уверен я что их действительно включат - всем не угодишь.
можно примеры патчей? ну в смысле - пакет и краткое описание.
> Бывают вообще курьезные случаи - в gtk3 была возможность собирать без atk-bridge, который мне не нужен от слова совсем. Затем какой-то умник сделал его mandatory. Его спрашивают - нахуа? А он - меньше вариантов сборки - проще тестировать. Если бы он увидел "make menuconfig" busybox или ядра, его бы наверно инсульт хватил :) И что в итоге? Откатил я его изменения в 2013 году и до сих пор gtk3 собирается и работает без проблем без этого atk-bridge все с тем же патчем 2013 года. А потом все удивляются, почему в дистрибутиве минимуму 100500 пакетов для обычного десктопа
не, ну против ментейнеров пакета ментейнеры дистрибутива конечно обычно не идут. Но добавить такой патч и подправить ебилд (чтобы поведение изменялось USE флагом) - проблемы нет.
> Бывает конечно, что есть настроение и начинаешь экспериментировать с системой (типа как идея со смешанной линковкой), но это от перфекционизма в клинической стадии :)
мне кажется, у тебя просто слишком много свободного времени :D
> Потому, что в них придется разбираться и править. Как я сказал - мне нужна система идеально подогнана под мои задачи.дык а в чем проблема то? мне приходилось править ебилды, я даже доку по ним не открывал (а там были не просто опции сборки или патчи). Но в любом случае - один раз прочитать доку по ебилдам - и в путь. По сути, такой же псевдо-язык, как и в твоих примерах.
> if (video == "i915")
> 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 не помешал бы, для понимания.
> Сложнее и дольше модифицировать под свои нужды.
достаточно спорное утверждение. под свои нужды всегда можно выкинуть "лишнее" и оставить только то, что нужно именно тебе.
> Теряется прозрачность и понимание работы системы.
в каком месте оно теряется? открываю любой ебилд и понимаю, что там происходит. вся "магия" обычно в еклассах, но там тоже ничего сложного по большому счету нет.
> Да и сама система абстрагирования от опций через USE флаги мне не нравится: для каждого пакета нужно описывать все опции вместо того, что бы напрямую их указать.не нужно всё описывать для каждого пакета. есть глобальные настройки USE-флагов (большинство из них - в профиле), но ты можешь переопределить как глобальные, так и "локальные", для конкретного пакета. Где тут "непрямое указание"? Если тебе нужно для конкретного пакета включить или выключить конкретный USE флаг - ты это делаешь, не трогая остальные, которые остаются в соответствии с остальными настройками.
> На phoronix (https://www.phoronix.com/forums/forum/phoronix/latest-phoron...) правду говорят, что gentoo до сих пор привязан к gcc-4.9.4?привязан - сильно сказано. на сегодня именно эта версия отмечена разработчиками как последняя стабильная. К установке доступны 5.3 и 5.4, но они помечены как нестабильные - это значит, что в каких-то пакетах есть проблемы с этой версией компилятора. Так же доступна версия 6.3.0, но она "замаскирована", т.е. хочешь - ставь - но всё на твой страх и риск, тебя предупредили.
> Как у gentoo вообще toolchain собирается/обновляется?
в процессе стандартного обновления - установили новый, затем обновили старый. какие детали конкретно интересуют?
> Что нужно сделать, чтобы пресобрать систему с другой стандартной библиотекой C (musl)?
если вкратце - подключить оверлей, сменить профиль и пересобрать @world (с -e для надежности - пересоберется вообще всё)
> -p.dep = ["xorg", "flex", "bison"];
> +p.dep = ["xorg", "flex", "bison", "alsa-lib"];отлично, а теперь всё то же самое, для всех программ, которые умеют работать с alsa
> Вот и я о том же. Все равно все руками править и перепроверять.не совсем. ментейнеры уже проверили и поправили за тебя. там, где это 100% возможно (я насчитал около 1000 пакетов, это без учета версий) - ты можешь это сделать обычным USE флагом.
> Из распространенного - mesa и ff. Или что-то забыл?
я ж не знаю, что тебе нужно. я вообще статической линковкой не увлекаюсь.
mesa и ff- на данный момент ебилды в офф. дереве не поддерживают static. Но добавить это - задача на 5 минут. Другое дело - не факт, что не потребуется доработки каких-то других ебилдов... поэтому возможно задача затянется. Но я тут не вижу никаких потенциальных преимуществ у LFS. В gentoo ты просто копируешь нужные тебе ебилды в локальный оверлей, правишь их - и всё.> Наоборот - если библиотека используется только одним приложением, то статика выгоднее.
не так уж много библиотек используются только одним приложением. К тому же следить, что как используется.... увольте.
> У меня все конфиги сборки пакетов - ~800 строк lfs + ~1800 blfs. Что проще по-вашему править?
А сколько всего пакетов то? Я могу все эти конфиги поставить себе домой на десктоп, их же на рабочий комп, их же на рабочий сервер БД, их же на локальный NAS (Atom), их же жене на ноут и до куче матери на неттоп (тоже Atom)? И это я еще про raspberryPi молчу, куда я тоже могу вкатить всё ту же генту со всеми теми же "конфигами". И да, соберу я на каждом из этих устройств абсолютно разные системы, т.к. требования везде разные.
> Если пакет собирается через ./configure --prefix=/usr && make && make install, я просто добавляю одну строку в конфиг (и + одну если есть зависимости):
соглашусь, ебилд будет несколько "жирнее". Другое дело, что я уже давно не встречал пакетов, ебилдов для которых нет в оверлеях.
> дык а в чем проблема то? мне приходилось править ебилды, ...Если хочется странного, то расковыривать "прослойку" бывает нудно и утомительно, особенно если знаешь что надо сделать по сути и 99.9% времени тратишь на уговоры прослойки.
Своя прослойка ближе...
> Если хочется странного, то расковыривать "прослойку" бывает нудноКакая прослойка? Просто копируешь ebuild и добавляешь что нужно. Если не добавил функцию распаковки, используется дефолтная, если добавил - твоя.
> Какая прослойка?ebuild над autotools + make + ... или что там оригинальный автор нагородил.
> Какая прослойка?
>> ebuild над autotools + make + ... или что там оригинальный автор нагородил.То есть bash скрипт, который запускет последовательно autotools + make + ... ? А что сложного-то? Хочешь - исходники смотри, хочешь - документацию. Не хочешь - забей и просто пропиши сам что тебе нужно. Там основной принцип - если ты не указываешь явно, используется дефолтный механизм (который достаточно неплох), если указываешь - используется твой.
> чет не увидел преимуществ перед gentoo... она все эти требования покрываетгвидобейсиком. в три слоя.
В генте жеж питон
Отсутствие системды не плюс, а минус. Как же тупые фанатики до сих пор не поняли...
> Отсутствие системды не плюс, а минус. Как же тупые фанатики до сих
> пор не поняли...жесткая привязка к чему либо - всегда минус,ибо отсутствие выбора. мне лично systemd не дает никаких преимуществ - все покрывается openrc. какой смысл мне переходить на systemd?
к тому же, на серверах systemd мне уже не раз подкидывало проблем. а я не хочу невнятного поведения на своих десктопах.
В чем плюс systemd для личной системы? Я еще могу понять его преимущества в дистрибутиве, так как он должен работать на большом количестве конфигураций с заранее неопределенным кругом задач. Но зачем он в простой системе, где вся система инициализации - 100-300 строк практически полностью линейных скриптов?
> В чем плюс systemd для личной системы? Я еще могу понять его
> преимущества в дистрибутиве, так как он должен работать на большом количестве
> конфигураций с заранее неопределенным кругом задач.... и неопределённым поведением вдогонку :)
У всех LFS разный. У меня такой: https://goo.gl/photos/WmVgh72YZsww6F3N9 .Для x86_64 свою сборку назвал Saahriktux, но до распространяемого дистрибутива оно пока ещё так и не доросло. А для Raspberry Pi собираю на основе pilfs'а, и вот оно таки доросло до полноценного дистрибутива - Pisaahriktux'а: https://www.linux.org.ru/forum/talks/13005910 . Более актуальную ссылку на последнюю версию можно найти на моём сайте (saahriktu.org), сейчас она такая: https://cloud.mail.ru/public/ABGn/6ACeGHmJi .
Ждем еще Ваших программ и сборок. Они всегда радуют и веселят весь ресурс.
Я бы ещё понял если бы не игрушки ( ну да большая привычка к контрастному зелёному на чёрном, может мозг уже перестроился под это ), но количество игрушек, которое намекает на бестолковое проведение времени наводит на разные мысли, но я всё-же надеюсь что вы их "отскриншотили" в образовательных целях...
В целях намёка на десктопное применение в качестве основной системы без дуалбута.
Классное руководство, но собирать я его, конечно, не буду
А может и не классное, потому что не читал и не буду.
> переход на ядро Linux 4.9А 4.10 как-то отличается или 4.8, через олдконфиг все прекрасно собирается
Не пробовал, но должно получиться.
а есть набор для офлайн-сборки, типа *скачал, уехал на необитаемый остров и там ближайший год сиди, компиляй на своём пентиуме 2*?
> а есть набор для офлайн-сборки, типа *скачал, уехал на необитаемый остров и
> там ближайший год сиди, компиляй на своём пентиуме 2*?http://www.linuxfromscratch.org/lfs/view/development/wget-list
Всё уже украдено до нас,
в смысле одним тарболом можно взять все сорцы для LFS не качая wget'омftp://ftp.lfs-matrix.net/pub/lfs/lfs-packages/
+ скрипты и свой конфиг для ядра, и еще... мы так уже к сборке скоро перейдем.
Что значит "Есть набор для оффлайн сборки" ?
1. Взял книжку в html(есть и в pdf, но не нужно).
2. Взял тарбол, где всея тексты lfs (еще скрипты).
3. На любой помойке нашел машину лучше, чем пень-2.
4. Прикрутил чрут и собирай.А вообще, сам вопрос какбэ намекает, что LFS тебе еще не нужен.
И не будет нужен. Нету радости lfs'у от буратин.
Да на втором пне нормуль. Ты на N900 собери )))
> Да на втором пне нормуль. Ты на N900 собери )))Под N900 потенциально могу. Кроссом.
> Что значит "Есть набор для оффлайн сборки" ?Ну, Debian с dev-тулзами -- в комплекте?
Набор,- именно тот, что был уже указан: книжка + сорцы.
> Набор,- именно тот, что был уже указан: книжка + сорцы.Лучше только книжка, с распечатанными сорцами
Сразу скажи, читать лень/некогда.Вопрос апологетам: как боретесь с засиранием системы? Т.е. поставил пару сотен пакетов, через некоторое время какие-то зависимости могут стать ненужными. Как удалить лишнее? И дело не в "тебе чё, пару гигов жалко". Проблема решена?
doas pkg autoremove
>Как удалить лишнее?По файлу руками.
Читай, что пишет об этом Джерард, есть на русском:http://www.opennet.ru/docs/RUS/blfs6/introduction/important....
и другие переводы.
А вообще, если пакетов много (blfs) ->
для управления сборки из сорцов удобен stow.
> А вообще, если пакетов много (blfs) ->
> для управления сборки из сорцов удобен stow.Вселенная, наверное, уже пишет книжку "LFS (guix)"... Надо только подождать. //"Войну т мир"-то уже дописала.
http://porg.sourceforge.net
> Сразу скажи, читать лень/некогда.
> Вопрос апологетам: как боретесь с засиранием системы? Т.е. поставил пару сотен пакетов,
> через некоторое время какие-то зависимости могут стать ненужными. Как удалить лишнее?
> И дело не в "тебе чё, пару гигов жалко". Проблема решена?Примерно так же как предлагается в хренях типа CoreOS. Новой сборкой.