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

403

根据文件系统层次结构标准，/opt用于“附加应用程序软件包的安装”。 /usr/local是“供系统管理员在本地安装软件时使用”。这些用例看起来非常相似。软件不包含的分布通常是默认配置为在安装/usr/local或/opt没有特别无缘无故为他们选择。

我是否缺少某些区别，或者两者都做同样的事情，但是出于历史原因而存在？

directory-structure fhs

— 补丁
source

3

我的理解是这/usr/local是/usr文件系统的本地版本，而/opt杂项则是占位符。

— yasouser 2011年

5

类似的问题在向Ubuntu的，超级用户

— kenchew

出于历史原因而离题：了解bin，sbin，usr / bin，usr / sbin split。

— Alexey

Linux：目录/ opt与/ usr / local

— El borito

357

虽然两者都旨在包含不属于操作系统的文件，/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/binOS命令的源代码位于/usr/src/bin和中/usr/src/usr.bin，而本地开发的命令的源位于中/usr/local/src，其二进制文件在中/usr/local/bin。没有包装的概念（压缩包之外）。

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

— 耶利亚格雷
source

53

/ usr / local，用于自我，内部，编译和维护的软件。/ opt用于非自我，外部，预包装的二进制/应用程序捆绑包安装区域。嗯...我们没有所有内容的C：\ program文件；-)

— Nikhil Mulley'2

2

“另一方面，/ opt是安装未捆绑软件包的目录”“未捆绑”软件包在这里是什么意思？

— 凯文·惠勒

1

@KevinWheeler在下一句话中进行解释。取消捆绑是指软件包不是操作系统分发的一部分，而是由独立的来源提供。

— jlliagre

2

@jlliagre centos docs *状态“例如，如果/ usr /目录从远程主机作为只读NFS共享挂载，则仍然可以在/ usr / local /目录下安装软件包或程序”我不知道谁是对的，但这似乎与您关于FHS薄弱地区的主张相矛盾。（*源centos.org/docs/5/html/5.1/Deployment_Guide/...）

— 凯文惠勒

1

@KevinWheeler正是我所指的弱点。根本不可能在远程只读目录中安装软件包或程序。解决方法是在/ usr / local上挂载本地文件系统，但这看起来像是临时工作，而不是经过适当设计的工作。

— jlliagre 2015年

84

基本区别在于/usr/local不是由系统打包程序管理，而是仍遵循标准的UNIX部署规则的软件。

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

/opt另一方面是针对不遵循此要求并以整体方式部署的软件。这通常包括以“ Windows”样式打包的商业和/或跨平台软件。

— Let_Me_Be
source

12

我不同意你的观点。FHS标准规定，安装在/ opt子目录中的软件包必须将其主机特定文件安装在/ opt外部，分别在/ etc / opt / package下用于配置文件，在/ var / opt / package下用于日志，假脱机等。/ opt实际上比/ usr / local更接近于UNIX部署规则，后者将所有内容都放在一个只读目录下，但出于明显的原因而不能。

— jlliagre

5

当然，如果我要制作选择包装并想声明符合FHS。否则，该标准就是您所谓的“准则”。仅仅是因为NetBeans不使用/ etc / opt / netbeans并不能阻止我将它放在系统范围内的/ opt或单用户的$ HOME / .local / opt中。

— 2015年

1

@jla我认为您的最后评论是直接针对我的，因此在回复OP或回复作者的其他人时，请使用@ xxx。关于/ etc / opt，FHS并不是说这是推荐位置（作为指导），而是必填位置。您或Netbeans开发人员可以自由地违反该标准，因为没有执行该标准的权限，但是请不要告诉做错了。这只是不幸的误解或故意的违反。

— jlliagre

8

@jlliagre作为我系统的管理员，FHS是一套准则。/ opt目录是放置单一的/ opt / <package>或/ opt / <provider>软件的常识。当我安装要使用<package | provider> / all / data / required / to / support的软件包时，即使提供者未能遵循最新FHS的每个细节，它也会进入opt /。我可能会发送电子邮件或报告错误，但是我不会将那个整体式软件包放在其他地方以使我的系统上的FHS感觉更好。

— 2015年

1

@jlliagre我在/ opt中安装了很多东西，在/ etc / opt中没有创建文件。应该？

— erm3nda

18

它们确实非常相似，并且使用其中一个更是一种见解。Linux期刊在此处就此确切主题进行了要点/对点讨论。

— 菲尔弗
source

9

噢亲爱的。我并不是故意将自己拖入一场“圣战”。

— 补丁

13

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

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

不幸的是，大多数make install脚本将文件推送到其中，/usr/local而不仅仅是在其中建立符号链接：-/

— 佩波卢安
source

2

重点是什么？如果仍然要进行符号链接，为什么不将原始文件放在首位呢？

— Let_Me_Be 2011年

8

只是对make install将文件推送到目标上进行评论/usr/local; 可以通过将--prefix=命令行参数传递给./configure脚本来轻松更改此功能，或者，如果没有./configure脚本，则可以将参数传递给make目标，如下所示：make --prefix=/usr install。

— 肖恩·C，

3

/ opt是$ PATH中包含的标准目录吗？我知道/ usr / local是。

— LawrenceC

5

@Let_Me_Be的好处是保留旧版本非常容易。假设我在/opt/foo-1.1和中有两个版本的'foo' /opt/foo-1.2。当我升级时，foosymlink /usr/local/bin指向foo-1.2。如果出于某种原因需要回滚，则只需将符号链接替换为指向foo-1.1的符号链接。如果几周后1.2仍然可以，请rm -rf /opt/foo-1.1快速，干净地删除旧版本。

— pepoluan 2011年

7

@ultrasawblade不，不是。绝对不应该毕竟，根据FHS，必须将/ opt细分为带有软件包名称的子目录。将一切塞进PATH是灾难的必经之路。应用程序应该将自己安装在/ opt下，并将用户调用的程序符号链接到/ usr / local / bin（或sbin）。

— pepoluan 2011年

11

首先，我认为没有严格的答案；根据他们的背景，不同的管理员会有不同的意见。从历史上看，它/usr/local排在第一位。这是IIRC伯克利的公约。在系统V的开发过程中的某个时刻，如果我没记错的话（这是很久以前的事了，而且我没有做笔记），那么就有一个决定或愿望是可以挂载/usr只读的，这意味着您无法向其中添加新软件；那可能就是为什么/opt 发明的原因。碰巧的是，确实有很多现成的软件确实为/usr这种想法所写，但从未真正起步。

我个人的喜好是/opt，每个产品都有单独的子目录；这使得移除产品成为的简单案例 rm -fr。但是，如果您所有的软件都是通过良好的软件包管理器安装的，则没关系，并且如果您安装的软件没有严格遵守这些约定，并且在的某处写入配置等/usr也没有关系，尽管出于相反的原因。

— 詹姆斯·坎泽
source

1

“”“所有软件都是通过良好的软件包管理器安装的”“”“，除非您仅使用常用软件。

— Pacerier '17

1

@Pacerier是可能的，这取决于您使用的发行版。无论使用哪种软件，它都可能在Arch用户存储库中，如果不是，则相对容易编写PKGBUILD。

— StarlitGhost

9

对于这个问题，我的看法略有不同。
尽管一切都在jlliagre的答案是正确的，对我的实际应用，在群集中部署软件时，归结为默认的环境变量和库的默认重用。

简而言之，- /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,...}etc。

— 丹妮
source