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

Question

Нам нравится использовать 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 на лету, чтобы поставить одну установку перед другой, чтобы использовать ее определенные инструменты? Мы что-то упустили?

Answer 1

Позвольте мне ответить на это с точки зрения 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 в процессе сборки. Однако это не поможет другим инструментам, если они не примут эту функцию также.

Answer 2

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

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

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

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

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

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

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

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