Как мы можем "убедить" fink, port и brew сосуществовать параллельно на OSX Mavericks?

Нам нравится использовать brew, но это не так много gnome формул набора инструментов, и мы можем установить gnome-terminal очень быстро с FinkCommander, Мы построили различные части gnome с нуля, но создавая brew формула просто чтобы получить gnome-terminal кажется излишним, когда он уже доступен.

Несмотря на это, у нас были проблемы со строительством gnome-terminal с FinkCommander то есть пока мы не удалили все brew ссылки на установленные компоненты из переменных среды; мы, конечно, должны были принять /usr/local/bin а также /usr/local/opt/gnu-tar/libexec/gnubin снаружи $PATH и просто ради удовольствия мы убедились ${DY}LD_LIBRARY_PATH не указал на /usr/local/lib и т. д. Это разрешено gnome-terminal построить и успешно установить с FinkCommander,

Кроме того, у нас есть программное обеспечение, которое мы хотим установить через brew, fink и port - но brew плохо играет с другими. Это привело к более общему вопросу: достаточно ли просто переключать переменные пути и среды для переключения между brew а также fink / port создавать среды и установки? Мы знаем, что нам нужно спрятаться brew от fink через переменные окружения при сборке gnome-terminal с FinkCommander и предположение, что для некоторых brew определенная формула, обратное верно.

Что вообще мы должны сделать, чтобы иметь лучшее из всех трех миров? То есть, что нужно сделать, чтобы все три, brew, fink, а также port, построен и установлен параллельно? Поскольку все управляемые пакеты были созданы с нуля, каждый пакет должен знать, где находятся его собственные динамически связанные библиотеки. Достаточно ли перемешать вокруг $PATH, $MANPATH & $DYLD_LIBRARY_PATH переменные среды на лету, чтобы поставить одну установку перед другой, чтобы использовать ее определенные инструменты? Мы что-то упустили?

Источник

2 ответа

Позвольте мне ответить на это с точки зрения MacPorts, откуда я пришел, поскольку эти проблемы сосуществующих инструментов управления программным обеспечением там не неизвестны. Самое главное, просто нет возможности удалить /usr/local из путей поиска компилятора по умолчанию. Это может привести к проблемам с некоторыми сборками, особенно во время мульти-архитектуры +universal сборник.

В начале проекта много лет назад MacPorts перешел на /opt/local во избежание проблем с другим программным обеспечением. Полная изоляция от /usr/local кажется невозможным только с помощью флагов конфигурации компилятора. К сожалению, разработчики Homebrew сознательно проигнорировали это и выбрали по умолчанию / usr / local. Хотя это звучит как хорошая идея, так как она уже указана в PATH, в конфигурации по умолчанию /usr/local/bin происходит только после /usr/bin, что делает невозможным перезапись любых инструментов командной строки. Таким образом, нет никакого преимущества использования /usr/local совсем.

Лучшее решение - установить Homebrew по любому другому пути (например, /opt/homebrew) или временно переименовать / usr / local перед сборкой и переименовать его потом:

sudo mv /usr/local /usr/local.off
... # do your compilation work
sudo mv /usr/local.off /usr/local

Как примечание на будущее, хотя MacPorts в своей текущей версии уже использует "песочницу" для всех сборок, в этой области есть улучшения для версии 2.3.0 или более поздней. Новый режим трассировки, который в настоящее время разрабатывается, позволит ограничить доступ всех файлов к тем файлам, которые требуются только для конкретной задачи сборки, скрывая такие места, как /usr/local а также /sw полностью из процесса сборки. Однако это не поможет другим инструментам, если они не примут эту функцию также.

Источник

Так как каждая система портов обычно имеет свои особенности (и случайный порт не удается построить из-за какой-то странности, скрытой в глубине пути зависимостей), у меня есть одна система с установленными параллельно HomeBrew, MacPorts и FreePorts. Для среды сборки обычно достаточно, чтобы они не могли обнаружить другие установки системы портов во время сборки и во время компиляции, чтобы разделить их, чтобы они не начинали создавать зависимости друг от друга, или, что еще хуже, отказывали и получали залог из-за зависимости, обнаруженной в неправильное дерево портов.

До сих пор было достаточно инициализировать чистую среду здания, в которой есть только системные каталоги (избегайте /usr/local для MacPorts, Fink, FreePorts, см. ответ Raims) + свои собственные целевые каталоги в своих путях поиска, пути компоновщика и т. д., как уже описано в вопросе выше.

Для сборки я предварительно отрисовываю дерево систем портов в порядке поиска по каталогам, чтобы избежать жалоб времени настройки на устаревшие версии, обнаруженные в стандартном MacOSX системой сборки портов. Для пользователя, использующего порт, безопаснее добавлять эти деревья, чтобы отдавать предпочтение двоичным файлам, предоставляемым ОС.

Если вам нужно скопировать установленные деревья портов, ditto будет инструментом выбора. Из справочной страницы:

ditto при копировании сохранит ветки ресурсов и информацию метаданных HFS, если не указано иное, используя --norsrc, Так же, ditto сохранит расширенные атрибуты и списки контроля доступа (ACL), если --noextattr или же --noacl передается.

Другой вариант будет /usr/bin/rsync -avSEH:

  • a режим Rchive,
  • v Erbose не является обязательным,
  • E сохранить расширенные атрибуты и ACL,
  • S правильно обрабатывать разреженные файлы (без расширения их до полной емкости, занимая больше места, чем оригинал), и
  • H сохранить жесткие ссылки.

Для tar который хорошо обрабатывает ACL (объясненные здесь) и расширенные атрибуты, взгляните на star очень зрелый (1982) tar реализация, которая до сих пор активно поддерживается его первоначальным автором. Вы можете скомпилировать его, используя одну из вышеупомянутых систем портов, или установить как часть schilytools,

Источник
Другие вопросы по тегам