/opt 和 /usr/local 有什么区别？

Question

/opt 和 /usr/local 有什么区别？

根据Filesystem Hierarchy Standard，/opt用于“附加应用程序软件包的安装”。 /usr/local是“供系统管理员在本地安装软件时使用”。这些用例看起来非常相似。未包含在发行版中的软件通常默认配置为安装在他们选择的任何一种/usr/local或/opt没有特定的韵律或原因。

我是否遗漏了某些差异，或者两者都做同样的事情，但由于历史原因而存在？

Answer 1

jll*_*gre 484

虽然两者都旨在包含不属于操作系统的文件，/opt并且/usr/local不打算包含相同的文件集。

/usr/local是安装管理员构建的文件的地方，通常使用make命令（例如，./configure; make; make install）。这个想法是为了避免与作为操作系统一部分的文件发生冲突，否则这些文件将被覆盖或覆盖本地文件（例如，/usr/bin/foo是操作系统的一部分，/usr/local/bin/foo而是本地替代品）。

下面的所有文件/usr都可以在操作系统实例之间共享，尽管在 Linux 中很少这样做。这是 FHS 有点自相矛盾的部分，因为/usr定义为只读，但/usr/local/bin需要读写才能成功本地安装软件。SVR4 文件系统标准是 FHS 的主要灵感来源，建议避免/usr/local并使用它/opt/local来克服这个问题。

/usr/local是原始 BSD 的遗产。当时，/usr/bin操作系统命令的源代码在/usr/src/bin和中/usr/src/usr.bin，而本地开发的命令的源在中/usr/local/src，它们的二进制文件在/usr/local/bin. 没有包装的概念（在 tarball 之外）。

另一方面，/opt是一个用于安装非捆绑包（即包不是操作系统发行版的一部分，而是由独立来源提供）的目录，每个包都在其自己的子目录中。它们已经是由独立的第三方软件分销商提供的完整软件包。与/usr/local东西不同，这些包遵循目录约定（或者至少应该遵循）。例如，someapp将安装在中/opt/someapp，其命令之一是/opt/someapp/bin/foo，其配置文件在中/etc/opt/someapp/foo.conf，其日志文件在/var/opt/someapp/logs/foo.access.

/usr/local，用于自我、内部、编译和维护的软件。/opt 用于非自身的、外部的、预打包的二进制/应用程序包安装区域。嗯...我们没有所有的 C:\program 文件;-) (86认同)
“另一方面，/opt 是安装未捆绑软件包的目录”这里的“未捆绑”软件包是什么意思？ (5认同)
@KevinWheeler 这在下一句中进行了解释。非捆绑意味着软件包不是操作系统发行版的一部分，而是由独立来源提供。 (5认同)
我将添加默认情况下`/usr/local/bin` 在路径上，而`/opt/<package>/bin` 文件夹不会自动添加到路径中。所以当我安装一个预建的软件时，我把它放在 `/opt` 中，但如果我需要从命令行启动它，我会在 `/usr/local/bin` 中为它添加一个符号链接。 (3认同)
@jlliagre centos docs* 声明“例如，如果 /usr/ 目录从远程主机作为只读 NFS 共享挂载，则仍然可以在 /usr/local/ 目录下安装软件包或程序”我不知道谁是对的，但这似乎与您关于 FHS 薄弱领域的说法相矛盾。(*来源 https://www.centos.org/docs/5/html/5.1/Deployment_Guide/s3-filesystem-usr-local.html) (2认同)
“我还在等待 /opt/local 出现...” — [Rob Landley](http://lists.busybox.net/pipermail/busybox/2010-December/074114.html) (2认同)
@JoshHabdas 我确实在我的一些机器上创建了一个 `/opt/local` 目录（违反了标准）。我对 Rob Landley 关于 `/home` 目录创建的声明持怀疑态度。AFAIK，它出现在他所说的至少 15 年后。没有证据表明它在早期的 Unix 中被使用。版本 7 (1977) 没有记录或使用它。它于 1985 年至 1988 年首次正式出现。 (2认同)

Answer 2

Šim*_*óth 109

基本的区别是/usr/local针对不由系统打包者管理但仍遵循标准的unix部署规则的软件。

这就是为什么你有/usr/local/bin，/usr/local/sbin /usr/local/include等等......

/opt另一方面是用于不遵循此规则并以整体方式部署的软件。这通常包括以“Windows”风格打包的商业和/或跨平台软件。

我不同意你的整体观点。FHS 标准规定，安装在 /opt 子目录中的软件包必须将其主机特定文件安装在 /opt 之外，分别在 /etc/opt/package 下用于配置文件和 /var/opt/package 下用于日志、假脱机等。/opt 实际上比 /usr/local 更接近于 unix 部署规则，后者将所有内容都放在一个目录下，该目录应该是只读的，但出于明显的原因不能是。 (14认同)
@jlliagre 作为我系统的管理员，FHS 是一套指导方针。/opt 目录是放置单片 /opt/<package> 或 /opt/<provider> 软件的常识性完善位置。当我安装一个想要使用 <package|provider>/all/data/required/to/support 的包时，它会进入 opt/，即使 provider 未能遵循最新 FHS 的每一个细节。我可能会发送电子邮件或报告错误，但我不会将这个整体包放在其他地方来让我的系统上的 FHS 感觉更好。 (13认同)
当然，如果我正在制作一个选择包并想声明 FHS 合规性。否则，标准更像是您所说的“指南”。仅仅因为 NetBeans 不使用 /etc/opt/netbeans 并不会阻止我将它放在 /opt 用于系统范围或 $HOME/.local/opt 用于单用户。 (7认同)
@jlliagre。含义：安装在`/opt` 中的软件应该在`/etc/opt` 文件夹中创建常规的.conf 文件吗？我有 Firefox、Hashcat 和其他在 repos 上不可用的示例。`/etc/opt` 完全是空的。 (3认同)
@jla 我假设您的最后一条评论是针对我的，因此在回复 OP 或回复作者的其他人时，请使用 @ xxx。关于 /etc/opt，FHS 没有说它是推荐位置（作为指导），而是强制位置。您或 Netbeans 开发人员可以自由地违反该标准，因为没有强制执行它的权力，但不要说做错了就是要走的路。这只是一个不幸的误解或故意侵犯。 (2认同)
@jlliagre 我在 /opt 中安装了很多东西，但在 /etc/opt 中没有创建任何文件。应该？ (2认同)
@erm3nda 这意味着您安装的软件包确实违反了 FHS。不确定“应该”是什么意思？ (2认同)
@jlliagre 您是否暗示有些软件根本无法以符合 FHS 的方式安装（不修改所述软件）？根据您的说法，用户应该在哪里安装违反通常约定的单体程序？ (2认同)
哦，看在基督的份上。我现在比以往任何时候都更加确信这些目录都没有任何意义。事情在 80 年代初期很平静，但到了 80 年代后期，随着人们急于模仿 Apollo 和 Sun 工作站，各种奇怪的事情开始出现。我一直认为这很大程度上与 BSD 比 SystemV（直到 System V r4）越来越受欢迎有关，但在这一点上，谁知道...... (2认同)

Answer 3

phi*_*lfr 19

它们确实非常相似，使用一个或另一个更多的是见仁见智。Linux杂志在关于这个话题确切这点/对位的讨论在这里。

Answer 4

pep*_*uan 16

就我个人而言，这就是比尔在@philfr 的链接中所说的：

在开发系统或沙箱上，拥有一个 /opt 目录，您可以在其中扔东西并查看它们是否有效，这很有意义。我知道我不会自己尝试包装东西。如果应用程序不起作用，您可以简单地 rm /opt/mytestapp 目录，该应用程序就是历史记录。当您运行大型部署时，打包可能有意义（有时我会打包应用程序），但很多时候，将内容扔到 /opt 中会很好。

不幸的是，大多数make install脚本将文件推入/usr/local而不是仅仅在那里制作符号链接：-/

只是为了评论`make install`目标将文件推送到`/usr/local`；通过将 `--prefix=` 命令行参数传递给 `./configure` 脚本，可以轻松更改此功能，或者如果没有 `./configure` 脚本，您可以将参数传递给 `make` 目标，例如所以：`make --prefix=/usr install`。 (10认同)
@Let_Me_Be 的好处是很容易保留旧版本。假设我有 2 个版本的 'foo'，分别位于 `/opt/foo-1.1` 和 `/opt/foo-1.2`。当我升级时，`/usr/local/bin` 中的 `foo` 符号链接指向 foo-1.2。如果由于某种原因我需要回滚，我只需将符号链接替换为指向 foo-1.1 的符号链接。如果几周后 1.2 没问题，快速的 `rm -rf /opt/foo-1.1` 可以快速干净地删除旧版本。 (9认同)
@ultrasawblade 不，它不是。并且永远不应该。毕竟，根据 FHS，/opt 必须细分为包含包名称的子目录。把所有东西都塞进 PATH 是一种万无一失的灾难方式。相反，应用程序应该将自己安装在 /opt 下，并将其用户调用的程序符号链接到 /usr/local/bin（或 sbin）。 (8认同)
/opt 是 $PATH 中包含的标准目录吗？我知道 /usr/local 是。 (4认同)
重点是什么？如果您无论如何都要制作符号链接，为什么不首先将原始文件放在那里？ (2认同)
FHS 3 说：“目录 /opt/bin、/opt/doc、/opt/include、/opt/info、/opt/lib 和 /opt/man 保留供本地系统管理员使用。软件包可能提供”前端-end”文件旨在（通过链接或复制）由本地系统管理员放置在这些保留目录中，但在没有这些保留目录的情况下必须正常运行。” 所以虽然我同意，/opt 不应该在路径上，并且符号链接应该在 /usr/local/ 中，但现在看来 /opt/bin、/opt/man 等。也是为了达到这个目的。因此，将 /opt/bin 添加到 PATH 是有意义的。 (2认同)

Answer 5

小智 14

首先，我认为没有严格的答案；不同的管理员根据他们的背景会有不同的意见。从历史上看，/usr/local先到先得；这是 IIRC 伯克利的会议。在 System V 开发过程中的某个时刻，如果我没有记错的话（这都是很久以前的事了，我没有做笔记），有一个决定或希望能够以/usr只读方式挂载，这意味着您无法向其中添加新软件；这可能就是/opt 发明的原因。碰巧的是，有太多现有的软件确实写了/usr这个想法，但从未真正实现过。

我个人的偏好是/opt，每个产品都有一个单独的子目录；这使得删除产品成为一个简单的案例 rm -fr。但是如果你所有的软件都是通过一个好的包管理器安装的，那没关系，如果你安装的软件没有严格遵守这些约定，并且在/usr.出于相反的原因。

@Pacerier 这是可能的，这取决于您使用的发行版。无论软件是什么，它都可能位于 Arch 用户存储库中，如果不是，则 PKGBUILD 相对容易编写。 (2认同)

Answer 6

Dan*_*i_l 11

我对这个问题的看法略有不同。
虽然jlliagre的答案中的所有内容都是正确的，但对我而言，在集群中部署软件时的实际应用归结为默认环境变量和默认重用库。

简单地说 -/usr/local并且它的所有子目录都在适当的环境变量中，例如PATHand MANPATH，并且/usr/local/lib{,64}在 ldconfig 的 ( /etc/ld.so.conf.d/) 中。

/opt/OTOH 不是——这在需要多个版本或冲突包在系统中共存时有利，但需要某种环境管理（例如，环境模块或软件集合），不利之处在于它可能会“浪费” " 通过复制共享库来存储空间，因为每个安装/opt都可以完全独立。

为了工作的共享性质，/usr/local假设例如二进制文件直接安装到/usr/local/bin（和手册页到适当的/usr/local/share/man/...）而不是/usr/local/app/{bin,share/man,...}等。

Answer 7

Jes*_*olm 5

我对这个老话题的看法略有不同。

如果我正在开发一个新工具，我打算将其成为操作系统的标准部分。
- 我安装它/usr/local并要求我的本地用户对其进行 alpha 测试。
当我想与公司外部的人一起进行 Beta 测试时......
- 我把它放进去是/opt因为对他们来说这是第三方产品。
- 我自己可能仍然拥有最先进的版本/usr/local
- 他们可能会得到一个 tarball，除非我建立了自己的软件包服务器。
- 但也许我确实用 SemVer 号发布它0.X.Y。
当更大的社区最终接受我的工具作为操作系统组件时，它就意味着
- 官方软件包被重新捆绑为操作系统的一部分
- 不再在/usr/local
- 不再在/opt
- 不再仅仅是一个tarball

如果我希望能够顺利接受，那么我就遵循FHS，从一开始就妥善包装。

如果我一开始就是一个牛仔，并且没有遵循 FHS，或者只是制作了 tarball 并且从未打包过它，那么在它被接受之前需要进行重构工作。

有些packages/tarballs永远无法摆脱/opt，有些永远无法摆脱/usr/local

但在我看来，这个流程很可能就是当时选择的初衷。

归档时间：	14 年，6 月前
查看次数：	380376 次
最近记录：	5 年，5 月前