/opt用于“安装附加应用程序软件包”。 /usr/local是“供系统管理员在本地安装软件时使用”。这些用例看起来非常相似。通常，默认情况下，通常将发行版中未附带的软件配置为安装在/usr/local或/opt中，没有特别的韵律或选择的理由。我是否缺少某些区别，或者两者都做了同一件事，但出于历史原因而存在吗？
#1 楼
虽然两者都设计为包含不属于操作系统的文件，但是/opt和/usr/local不能包含相同的文件集。使用/usr/local命令（例如make）。这样做的目的是避免与操作系统中的文件冲突，否则该文件可能会被覆盖或覆盖本地文件（例如，./configure; make; make install是操作系统的一部分，而/usr/bin/foo是本地替代文件）。尽管在Linux中很少这样做，但
/usr/local/bin/foo下的所有文件在OS实例之间都是可共享的。这是FHS有点自相矛盾的部分，因为/usr被定义为只读，但是/usr必须是可读写的，这样本地软件才能成功安装。 SHS4文件系统标准是FHS的主要灵感来源，建议避免使用/usr/local/bin，而应使用/usr/local来克服此问题。/opt/local是原始BSD的遗产。当时，/usr/local OS命令的源代码在/usr/bin和/usr/src/bin中，而本地开发命令的源在/usr/src/usr.bin中，其二进制文件在/usr/local/src中。没有打包的概念（外部tar包）。另一方面，/usr/local/bin是用于安装未捆绑软件包的目录（即，软件包不是操作系统发行版的一部分，而是由独立来源提供的） ，每个都在自己的子目录中。它们已经由独立的第三方软件发行商提供了完整的软件包。与/opt的东西不同，这些软件包遵循目录约定（或至少应该遵循）。例如，/usr/local将安装在someapp中，其命令之一是/opt/someapp，其配置文件将在/opt/someapp/bin/foo中，其日志文件在/etc/opt/someapp/foo.conf中。评论
/ usr / local，用于自我，内部，编译和维护的软件。 / opt用于非自我，外部，预打包的二进制/应用程序捆绑包安装区域。嗯...我们没有所有的C：\ program文件;-)
– Nikhil Mulley
2012年2月2日，12：49
“另一方面，/ opt是安装未捆绑软件包的目录”“未捆绑”软件包在这里是什么意思？
–凯文·惠勒
15年8月16日在1:54
@KevinWheeler在下一句话中进行解释。取消捆绑是指软件包不是操作系统分发的一部分，而是由独立的来源提供。
– jlliagre
15年8月16日在1:59
@jlliagre centos docs *状态“例如，如果/ usr /目录从远程主机作为只读NFS共享挂载，则仍然可以在/ usr / local /目录下安装软件包或程序”我不知道谁是对的，但这似乎与您关于FHS薄弱地区的主张相矛盾。 （*来源centos.org/docs/5/html/5.1/Deployment_Guide / ...）
–凯文·惠勒
2015年12月6日，11：44
@KevinWheeler正是我所指的弱点。根本不可能在远程只读目录中安装软件包或程序。解决方法是在/ usr / local上安装本地文件系统，但这看起来像是临时工作，而不是经过适当设计的工作。
– jlliagre
2015年12月6日13:05
#2 楼
基本区别是/usr/local适用于不是由系统打包程序管理的软件，但仍遵循标准的unix部署规则。 br />另一方面，/usr/local/bin适用于不遵循此规则并以整体方式部署的软件。这通常包括以“ Windows”样式打包的商业和/或跨平台软件。评论
我不同意你的观点。 FHS标准规定，安装在/ opt子目录中的软件包必须将其主机特定文件安装在/ opt外部，分别在/ etc / opt / packages下用于配置文件，在/ var / opt / package下用于日志，假脱机等。 / opt实际上比/ usr / local更接近于unix部署规则，后者将所有内容都放在一个只读目录下，但出于明显的原因而不能。
– jlliagre
13年4月4日在9:03
当然，如果我要选择包装并想声明符合FHS。否则，该标准就是您所谓的“准则”。仅仅因为NetBeans不使用/ etc / opt / netbeans并不能阻止我将它放在系统范围内的/ opt或单用户的$ HOME / .local / opt中。
– jla
15年5月14日在18:59
@jla我认为您的最后评论是针对我的，因此在回复OP或回复作者的其他人时，请使用@ xxx。关于/ etc / opt，FHS并不是说这是推荐位置（作为指导），而是必填位置。您或Netbeans开发人员可以自由地违反该标准，因为没有执行该标准的权限，但是不要告诉我们做错了。这只是不幸的误解或故意的违反。
– jlliagre
15年5月22日在11:15
@jlliagre作为我系统的管理员，FHS是一套准则。 / opt目录是放置单片/ opt /
– jla
15年5月27日在18:04
@jlliagre。含义：/ opt中安装的软件是否应该在/ etc / opt文件夹内创建常规的.conf文件？例如，我有Firefox，Hashcat和其他在回购协议中不可用的文件。 / etc / opt完全为空。
– m3nda
16年1月26日，1：11
#3 楼
它们确实确实非常相似，而使用一个或另一个只是一个见解。Linux期刊在此处就此确切主题进行了要点/对点讨论。
评论
噢亲爱的。我并不是故意将自己拖入一场“圣战”。
–补丁
2011年4月18日在15:01
@Patches，“计算机相关”这个统称之下的一切都是一场神圣的战争。即使到现在，即2020年，情况仍然如此。
–tgm1024--莫妮卡遭到虐待
1月19日7:03
我喜欢这个问题。这么多答案！
– Anthony Rutledge
3月13日21:13
#4 楼
就我个人而言，这就是Bill在@philfr的链接中所说的：在开发系统或沙箱上，有一个/ opt目录，您可以在其中扔东西并查看它们是否工作很有道理。我知道我不会自己打包东西来尝试它们。如果该应用程序无法正常运行，您可以简单地rm / opt / mytestapp目录，并且该应用程序为历史记录。在运行大型部署时（有时我打包应用程序），打包可能很有意义，但很多时候，最好在/ opt中扔东西。
不幸的是，大多数
make install脚本会将文件推送到/usr/local中，而不仅仅是在其中建立符号链接：-/ 评论
重点是什么？如果您仍然要进行符号链接，为什么不将原始文件放在首位呢？
–ŠimonTóth
2011年4月18日在9:54
只是评论make install目标将文件推送到/ usr / local；通过将--prefix =命令行参数传递给./configure脚本，可以轻松更改此功能，或者，如果没有./configure脚本，则可以将参数传递给make目标，如下所示：make --prefix = / usr安装。
– Sean C.
11年4月18日在11:45
/ opt是$ PATH中包含的标准目录吗？我知道/ usr / local是。
–LawrenceC
2011年4月18日在14:13
@Let_Me_Be的好处是保留旧版本非常容易。假设我有两个版本的'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可以快速，干净地删除旧版本。
– pepoluan
2011年4月18日在14:41
@ultrasawblade不，不是。绝对不应该毕竟，根据FHS，/ opt必须细分为带有软件包名称的子目录。将一切塞进PATH是灾难的必经之路。应用程序应该将自身安装在/ opt下，并将用户调用的程序符号链接到/ usr / local / bin（或sbin）。
– pepoluan
2011年4月18日在14:45
#5 楼
首先，我认为没有严格的答案；不同的管理员根据他们的背景会有不同的见解。从历史上看，
/usr/local排名第一；这是IIRC在Berkley召开的会议。在System V的开发过程中的某个时刻，如果我没记错的话（这是很久以前的事了，而且我没有做笔记），则可以做出决定或
渴望能够以只读方式安装
/usr，这意味着您无法为其添加新软件；这可能就是为什么发明了
/opt 的原因。碰巧的是，确实有很多确实写给
/usr的软件，但这个想法从来没有真正脱离现实。
我个人的喜好是
/opt，每个产品都有单独的子目录；这使得移除产品成为
rm -fr的简单案例。但是，如果您所有的软件都是通过好的软件包管理器安装的，则没关系，并且如果您安装的软件不严格遵守这些约定，并编写配置和尽管存在相反的原因，但在
/usr下的某个地方也没有。
评论
“”“所有软件都是通过良好的软件包管理器安装的”“”“，除非您仅使用常用软件。
–起搏器
17年11月1日在22:21
@Pacerier是可能的，这取决于您使用的发行版。无论使用哪种软件，它都可能位于Arch用户存储库中，如果不是，则相对容易编写PKGBUILD。
– StarlitGhost
18年11月2日在10:17
#6 楼
对于这个问题，我的看法略有不同。虽然jlliagre回答中的所有内容都是正确的，但在集群中部署软件时，对我来说的实际应用归结为默认环境变量和默认的lib重用。
简单地-
/usr/local及其所有子目录都在相应的环境变量中，例如PATH和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,...}等。#7 楼
总而言之，我的直觉答案...从2.2.6开始使用了我的FreeBSD，从9版本开始使用了Red Hat Linux。 >
在UNIX / Linux文件系统上，事物的安排更多地与约定和传统有关，而不是与绝对逻辑有关。 :-)
规则总是有一些例外。在一天结束时，您将决定最适合自己的设置（如果可以）。
#8 楼
对于这个旧主题，我的看法略有不同。如果我正在开发一个新工具，希望成为操作系统的标准部分。
我将其安装到
/usr/local，并要求我的本地用户对其进行alpha测试。 > 我把它放在
/opt中是因为对他们来说这是第三方产品。除非我设置了自己的软件包服务器，否则请得到一个tarball。但也许我会用
/usr/local SemVer数字发布它。当更大的社区最终接受了我作为OS组件的工具应该被
官方软件包作为OS的一部分重新捆绑在一起
在
0.X.Y中不再存在不再是
/usr/local 不再仅仅是
/opt 如果我希望它被顺利接受，那么我遵循FHS和我打包
如果我刚开始是牛仔，并且没有遵循FHS，或者只是制作了tarball而从未包装过，那么之前需要进行重构工作
有些
tarball / packages永远不会超出tarballs，有些永远不会超出/opt 但是我认为，这种流程很可能是原计划返回的然后选择它的时候。
评论
我的理解是/ usr / local是/ usr文件系统的本地版本，而/ opt是杂项的占位符。超级用户Ask Ubuntu中的类似问题
出于历史原因而离题：了解bin，sbin，usr / bin，usr / sbin拆分。
Linux：目录/ opt与/ usr / local