☰

我们如何“说服” fink、port 和 brew 在 OSX Mavericks 上并行共存？

tag-icon • tag-icon macos gnome macports homebrew fink
我们如何“说服” fink、port 和 brew 在 OSX Mavericks 上并行共存？

我们喜欢使用brew，但它没有很多gnome工具集公式，我们可以使用gnome-terminal非常快速地安装 。我们从头开始FinkCommander构建了 的各个部分，但只是为了获得 而创建一个公式似乎有些过头了，因为它已经可用了。gnomebrewgnome-terminal

gnome-terminal无论如何，我们在使用 进行构建时遇到了麻烦FinkCommander，直到我们brew从环境变量中删除了所有已安装的组件引用；我们当然必须从 中取出/usr/local/bin和，并且只是为了好玩，我们确保没有指向，等等。这样就可以使用 成功构建和安装。/usr/local/opt/gnu-tar/libexec/gnubin$PATH${DY}LD_LIBRARY_PATH/usr/local/libgnome-terminalFinkCommander

此外，我们还有一些想要通过以下方式安装的软件brew：fink和 port- 但brew没有与他人相处融洽。这引出了一个更普遍的问题：仅仅切换就足够了吗？小路和环境变量到切换 brew和fink/port 构建环境和安装我们知道我们需要隐藏 brew通过构建时的fink环境变量，并且假设对于某些定义的公式，反之亦然。gnome-terminalFinkCommanderbrew

总体而言，我们必须做什么才能同时实现这三个方面的最佳效果？也就是说，如何才能同时构建和安装 、 和 三个方面？brew因为所有托管finkport包都是从零开始建造的，包裹应该知道它们自己的动态链接库位于何处。 是否足以混淆$PATH、$MANPATH、 &$DYLD_LIBRARY_PATH环境变量飞行中安装一个在...前面另一个使用它定义的工具？我们遗漏了什么吗？

答案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构建过程中。但是，除非其他工具也采用此功能，否则这对它们没有帮助。

答案2

由于每个移植系统通常都有不同的怪癖（偶尔会因为依赖关系路径深处隐藏的怪异而导致移植失败），我有一个同时安装了 HomeBrew、MacPorts 和 FreePorts 的系统。对于构建环境，通常足以阻止它们在构建和编译时检测其他移植系统安装，以将它们分开，这样它们就不会开始相互依赖，或者更糟的是，由于在错误的移植树中检测到依赖关系而失败和放弃。

到目前为止，初始化一个只有系统目录的干净构建环境已经足够了（一定要避免/usr/localMacPorts、Fink、FreePorts，请参阅Raims 的回答) + 它自己的目标目录在其搜索路径、链接器路径等中已经按照上面的问题中描述的方式进行了描述。

对于构建，我按照搜索目录的顺序预先添加端口系统树，以避免在配置时收到端口构建系统在普通 MacOSX 中检测到的过时版本的投诉。对于运行端口的用户来说，附加这些树以优先考虑操作系统提供的二进制文件更为安全。

如果需要复制已安装的端口树，ditto将是首选工具。从手册页中：

ditto复制时将保留资源分支和 HFS 元数据信息，除非使用 另有指示--norsrc。类似地，ditto将保留扩展属性和访问控制列表 (ACL)，除非传递--noextattr或。--noacl

另一个选择是/usr/bin/rsync -avSEH：

  • a归档模式，
  • verbose 是可选的，
  • E保留扩展属性和 ACL，
  • S正确处理稀疏文件（不将其扩展到其最大容量，占用比原始文件更多的空间），并且
  • H保留硬链接。

对于tar处理 ACL 的（解释这里) 和扩展属性，请查看star，这是一个非常成熟的 (1982)tar实现，其原作者仍在积极维护。您可以使用上述移植系统之一编译它，也可以作为schilytools。

相关内容