> как-то сильно сложно - это ж нужно для разных версий разные патчи
> иметь, по именам их фильтровать?Да, но что в этом сложного?
Вот пример из моей системы:
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 пакетов для обычного десктопа ...
Бывает конечно, что есть настроение и начинаешь экспериментировать с системой (типа как идея со смешанной линковкой), но это от перфекционизма в клинической стадии :)
