How can we "persuade" fink, port, & brew to coexist in parallel on OSX Mavericks?

869
Billy McCloskey

We like to use brew, but it doesn't have a lot of gnome toolset formulae, and we can install a gnome-terminal very quickly with FinkCommander. We've built various parts of gnome from scratch, but creating a brew formula just to get the gnome-terminal seems overkill, when it is already available.

Regardless, we were having trouble building gnome-terminal with FinkCommander, that is until we removed all brew installed component references from environment variables; we certainly had to take /usr/local/bin and /usr/local/opt/gnu-tar/libexec/gnubin out of $PATH, and just for kicks, we made sure $LD_LIBRARY_PATH didn't point into /usr/local/lib, etc. This allowed gnome-terminal to build & install successfully with FinkCommander.

Further, we have software which we want to install via brew, fink, and port - but brew does not play well with others. This has led to the more general question: Is it enough just to toggle path and environment variables to switch between brew and fink/port build environments and installations? We know we need to hide brew from fink via environment variables when building gnome-terminal with FinkCommander, and the assumption is that for some brew defined formula, the reverse is true.

What in general must we do to have the best of all three worlds? That is, what to do to have all three, brew, fink, and port, built and installed in parallel? Because all the managed packages were built from scratch, each package should know where their own dynamically linked libraries are located. Is it enough to jumble around the $PATH, $MANPATH, & $DYLD_LIBRARY_PATH environment variables on the fly to put one installation in front of another to use its defined tools? Are we missing anything?

2
Идея состоит в том, чтобы создать 3 маленькие виртуальные машины, цель которых в жизни состоит в том, чтобы создавать "выпуски" brew`, `fink`, &` port`, которые экспортируются и монтируются, или даже rsync'd, в правильное расположение на хосте. , Следовательно, сборки будут строиться на основе экстентов библиотек на хосте, но не будут мешать друг другу при сборке, и только необходимые пути bin, lib, man и т. Д. Будут экспортированы в соответствующие им места на хосте. Billy McCloskey 10 лет назад 2
rsyncing и монтирование с помощью парадигмы brew не будут работать слишком хорошо, поскольку уже используется уровень косвенности brews, т. е. инструменты sym связаны с / usr / local / bin, поэтому мы не можем просто скопировать установку на место, но мы бы Нужно управлять ссылками на встроенные инструменты. Billy McCloskey 10 лет назад 0
У меня никогда не было проблем с этим, хотя. Fink, MacPorts и Brew ВСЕ установлены на моем компьютере, и все они прекрасно играют. Brew вызывает * предупреждение *, когда находит другие, но все равно работает нормально. Caleb Xu 10 лет назад 0
Да, у меня все установлено в одно и то же время, и я задаюсь вопросом о предупреждениях "доктора варения". Единственное, что я обнаружил, что может быть проблематично, это то, что инструменты gnu, похоже, не обрабатывают ACL (например, `gtar`), который является функцией, а не проблемой конфигурации сборки - конечно, если какой-то другой инструмент зависит от существования этих функций ... Billy McCloskey 10 лет назад 0
Tar не может обрабатывать списки ACL. Для реализации, которая хорошо обрабатывает ACL (объяснено [здесь] (http://cdrtools.sourceforge.net/private/star-acl.html)) и расширенные атрибуты, взгляните на «звезду», очень зрелую (1982 г.) ` Реализация tar, которая до сих пор активно поддерживается ее первоначальным автором, вы можете либо скомпилировать, используя одну из вышеупомянутых систем портов, либо установить как часть [schilytools] (http://schilytools.sourceforge.net). Tatjana Heuser 8 лет назад 0

2 ответа на вопрос

3
raimue

Let me answer that from the MacPorts perspective I come from, as these problems of co-existing software management tools are not unknown there. Most importantly, there simply is no way to remove /usr/local from the default compiler search paths. This may lead to problems with some builds, especially during a multi-architecture +universal compilation.

In the beginning of the project many years ago, MacPorts switched to /opt/local in order to avoid problems with other software. Total isolation from /usr/local does not seem to be possible at all by compiler configuration flags alone. Unfortunately, Homebrew developers deliberately ignored this and chose /usr/local as their default. While it sounds like a good idea as it would be already listed in PATH, in the default configuration /usr/local/bin only occurs after /usr/bin, making it impossible to overwrite any command line tools. So there is no advantage of using /usr/local at all.

Best solution is to either install Homebrew to any other path (for example /opt/homebrew), or to rename /usr/local temporarily before building and rename it back afterwards:

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

As a side note for the future, while MacPorts in its current version is already using a sandbox for all builds, there are improvements in this area coming for version 2.3.0 or later. The new trace mode currently in development would allow to limit all file access to those files required for the particular build task only, hiding locations like /usr/local and /sw completely from the build process. However, that won't help with other tools unless they adopt this feature as well.

1
Tatjana Heuser

Since each port system usually comes with different quirks (and the occasional port failing to build due to some weirdness hidden deep down its path of dependencies), I've got one system with HomeBrew, MacPorts and FreePorts installed in parallel. For the build environment, it's usually sufficient to keep them from detecting the other port system installations during build and compile time to keep them separated so they don't start weaving dependencies upon each other, or worse fail and bail due to a dependency detected in the wrong port tree.

So far, it has been enough to initialize a clean building environment that only has the system directories (make sure to avoid /usr/local for MacPorts, Fink, FreePorts, see Raims answer) + its own target directories in its search paths, linker path, etc the way already described in the Question above.

For building, I preprend the port systems tree in the order of directories searched, to avoid getting configure-time complaints about outdated versions detected in the stock MacOSX by the port build system. For the user running the port, it's safer to append those trees, to give preferrence to the OS-supplied binaries.

If you need to copy the installed port trees, ditto would be the tool of choice. From the manpage:

ditto will preserve resource forks and HFS meta-data information when copying unless instructed otherwise using --norsrc . Similarly, ditto will preserve extended attributes and Access Control Lists (ACLs) unless --noextattr or --noacl is passed.

Another option would be /usr/bin/rsync -avSEH:

  • archive mode,
  • verbose is optional,
  • E to preserve extended attributes and ACLs,
  • S to handle sparse files correctly (without expanding them to their full capacity, taking more space than the original), and
  • H to preserve hard links.

For a tar that handles ACLs (explained here) and extended attributes well, take a look at star, a very mature (1982) tar implementation that is still actively maintained by its original author. You can either compile it using one of the aforementioned ports systems, or install as part of schilytools.

Похожие вопросы