Исправление slovazap, (текущая версия) :
Это значит что это прописано в их Porter’s Handbook, как бы оно ни называлось.
Много где много чего прописано, что невозможно соблюсти на практике. Да и не нужно.
Не надо выдавать желаемое за действительное. На Celeron N3050 + 2G RAM
Не выдавайте - никому вы со своим селероном не сдались.
Но для этого нужно сделать свою копию дерева портов и похакать.
Без копии дерева портов вообще нет, не понимаю к чему вы это.
Во-первых это надо редко, во-вторых в портаже за это отвечают еклассы.
Вы сказали как аргумент за portage что можно хакать - когда я сказал что хакать можно и FreeBSD говорите что редко надо. Уж определитесь. Как там оно называется к дискуссии отношения не имеет.
Большая часть ебилдов не имеют в себе логики вообще, всё вынесено в еклассы.
Открыл первый попавшися ебилд, в src_prepare вызывается sed, потом epatch, потом eautoreconf, в src_configure - econf. Во FreeBSD будет GNU_CONFIGURE=true, патч достаточно положить в files, а для sed есть макрос. О, узнал что оказывается ещё и || die надо писать руками, это сразу куча граблей.
Я понимаю что поведение epatch/eautoreconf/econf можно менять, но во FreeBSD то же самое во-первых, в порте занимает в 3 раза меньше строк, во-вторых настраивается гораздо гибче - например, для портов использующих configure можно начать делать дополнительные действия во всех фазах - patch, configure, build и install фазах, не меняя ни одного порта. А для sed (который REINPLACE_CMD) не трогая ни одного порта недавно добавили механизм диагностики выявляющий вызовы sed’а которые ничего не меняют - т.е. ненужные или ошибочные. В portage такое можно сделать только заменив все sed’ы на какие-нибудь esed’ы. И так с любой командой.
Так что императивщина здесь работать никогда не будет, сколько бы полиморфизма под ней не лежало.
Ну а в портах не поменяешь логику per-package
Логика отдельного порта меняется в отдельном порте, глобальная логика меняется в Mk, она может действовать на все порты или что-то выбирать по любым условиям, вплоть до выбора отдельных портов по именам. Собственно не вижу чего тут может не хватать.
(а в портаже можно не только для конкретного ебилда, а ещё и для конкретной версии, а порты до сих пор могут держать только одну версию пакета).
Ну во-первых, где надо это замечательно решается несколькими портами. И это работает гибче, потому что в зависимости от ситуации общий код можно не дублировать, а положить в какой-нибудь common.mk, или наследовать Makefile’ы через MASTERDIR, или наоборот полностью разделить порты, а не иметь общую свалку патчей для разных версий.
Во-вторых, самой по себе возможности иметь несколько версий ебилдов грошь цена - сразу несколько версий не поставишь, софт с какими-то версиями зависимостей может перестать собираться и т.д., вообще разные комбинации версий не тестируются потому что это принципиально невозможно в силу комбинаторики. Т.е. все эти версионированные ебилды - просто мёртвый код и минное поле. Единственный практический юзкейс для этого - откатиться при проблемах после обновления, но нужно это так редко что и под FreeBSD не будет проблемой вытащить из svn предыдущую версию порта.
Эти 2% (ну может чуть-чуть больше) с MAKE_JOBS_UNSAFE способны съесть мозг.
Не больше - 1.94%. Не видел ни одного пакета из них который сколь либо долго собирается. А я в poudriere регулярно собираю тысячи пакетов. Последовательно, потому что work на tmpfs. График загрузки CPU получается вполне в полку.
Так у poudriere и make.conf свой.
Хотите свой, хотите сделайте симлинк на системный. При чём тут вообще make.conf?
Исходная версия slovazap, :
Это значит что это прописано в их Porter’s Handbook, как бы оно ни называлось.
Много где много чего прописано, что невозможно соблюсти на практике. Да и не нужно.
Не надо выдавать желаемое за действительное. На Celeron N3050 + 2G RAM
Не выдавайте - никому вы со своим селероном не сдались.
Но для этого нужно сделать свою копию дерева портов и похакать.
Без копии дерева портов вообще нет, не понимаю к чему вы это.
Во-первых это надо редко, во-вторых в портаже за это отвечают еклассы.
Вы сказали как аргумент за portage что можно хакать - когда я сказал что хакать можно и FreeBSD говорите что редко надо. Уж определитесь. Как там оно называется к дискуссии отношения не имеет.
Большая часть ебилдов не имеют в себе логики вообще, всё вынесено в еклассы.
Открыл первый попавшися ебилд, в src_prepare вызывается sed, потом epatch, потом eautoreconf, в src_configure - econf. Во FreeBSD будет GNU_CONFIGURE=true, патч достаточно положить в files, а для sed есть макрос. О, узнал что оказывается ещё и || die надо писать руками, это сразу куча граблей.
Я понимаю что поведение epatch/eautoreconf/econf можно менять, но во FreeBSD то же самое во-первых, в порте занимает в 3 раза меньше строк, во-вторых настраивается гораздо гибче - например, для портов использующих configure можно начать делать дополнительные действия во всех фазах - patch, configure, build и install фазах, не меняя ни одного порта. А для sed (который REINPLACE_CMD) не трогая ни одного порта недавно добавили механизм диагностики выявляющий вызовы sed’а которые ничего не меняют - т.е. ненужные или ошибочные. В portage такое можно сделать только заменив все sed’ы на какие-нибудь esed’ы. И так с любой командой.
Так что императивщина здесь работать никогда не будет, сколько бы полиморфизма под ней не лежало.
Ну а в портах не поменяешь логику per-package
Логика отдельного порта меняется в отдельном порте, глобальная логика меняется в Mk, она может действовать на все порты или что-то выбирать по любым условиям, вплоть до выбора отдельных портов по именам. Собственно не вижу чего тут может не хватать.
(а в портаже можно не только для конкретного ебилда, а ещё и для конкретной версии, а порты до сих пор могут держать только одну версию пакета).
Ну во-первых, где надо это замечательно решается несколькими портами. И это работает гибче, потому что в зависимости от ситуации общий код можно не дублировать, а положить в какой-нибудь common.mk, или наследовать Makefile’ы через MASTERDIR, или наоборот полностью разделить порты, а не иметь общую свалку патчей для разных версий.
Во-вторых, самой по себе возможности иметь несколько версий ебилдов грошь цена - сразу несколько версий не поставишь, софт с какими-то версиями зависимостей может перестать собираться и т.д., вообще разные комбинации версий не тестируются потому что это принципиально невозможно в силу комбинаторики. Т.е. все эти версионированные ебилды - просто мёртвый код и минное поле. Единственный практический юзкейс для этого - откатиться при проблемах после обновления, но нужно это так редко что и под FreeBSD не будет проблемой вытащить из svn предыдущую версию порта.
Эти 2% (ну может чуть-чуть больше) с MAKE_JOBS_UNSAFE способны съесть мозг.
Не больше - 1.94%. Не видел ни одного пакета из них который сколь либо долго собирается. А я в poudriere регулярно собираю тысячи пакетов. Последовательно, потому что work на tmpfs. График загрузки CPU получается вполне в полку.
Так у poudriere и make.conf свой.
Хотите свой, хотите сделайте симлинк на системный. При чём тут вообще make.conf?
Отвечу коротко: wine.
Ну так i386-wine сделали, никаких мультилиб не понадобилось. А если оно больше ни для чего не нужно, то не должно быть и увеличивающих сложность глобальных механизмов.