我应该将应用程序放入/ usr / local还是/ usr / local / share？

21

什么是“标准”-我应该将应用程序（不仅仅是二进制文件，而是整个发行版）放到/ usr / local或/ usr / local / share中。

例如scala或weka-它包含示例，二进制文件，库等。原来如此

/usr/local/scala-2.9.1

要么

/usr/local/share/scala-2.9.1

由于我是唯一的管理员，这对我来说并不重要，但是我更喜欢使用广泛使用的东西，而不是出于我自己的习惯。

重要说明：我不是在问什么情况，您应该将应用程序分为/ usr / local / bin，/ usr / local / lib等。相反，我是在问什么情况，您必须为整个应用程序保留一个主目录。

software-installation directory-structure application

— 格林曼
source

6

我认为/ opt在这种情况下更为习惯。

— Faheem Mitha

@Faheem Mitha，很好。多亏了您，我找到了这样的解释“ / opt /'provider'目录树，类似于Windows将新软件安装到其自己的目录树C：\ Windows \ Progam Files \“ Program Name”的方式。 online_books / linux_beginner_books / ......莫非你请？张贴作为回答您的意见，所以我想它标记为答案，谢谢。

— greenoldman

@greenoldman：还请注意，将所有文件保存在一个目录中不是在Unix中安装应用程序的“标准”方式。/opt确实是正确的答案，但是传统的Unix / Linux软件并未 “广泛使用” 它。有很大的原因在多个显示目录分割你的文件，并且还者区分/usr来自/usr/local

— MestreLion

例如，将所有应用程序中的所有可执行文件保存在一个/usr/bin（或/usr/local/bin）中，可以使$ PATH可以访问所有软件，而无需为每个软件进行编辑，这是Windows中不存在的概念

— MestreLion，2013年

19

我认为/ opt在这种情况下更为标准。下面引用了文件系统层次结构标准中的相关部分。

发行版可以在/ opt中安装软件，但在未经本地系统管理员同意的情况下，不得修改或删除由本地系统管理员安装的软件。

基本原理在UNIX社区中，将/ opt用于附加软件是一种公认的惯例。基于系统V接口定义（第三版）的系统V应用程序二进制接口[AT＆T 1990]提供了一个/ opt结构，该结构与此处定义的结构非常相似。

英特尔二进制兼容性标准v。2（iBCS2）也为/ opt提供了类似的结构。

通常，在系统上支持软件包所需的所有数据都必须存在于/ opt /中，包括打算复制到/ etc / opt /和/ var / opt /中的文件以及/ opt中的保留目录。

使用/ opt对发行版进行较小的限制是必要的，因为在发行版安装的软件和本地安装的软件之间可能会发生冲突，尤其是在某些二进制软件中找到固定路径名的情况下。

/ opt /下面的目录结构由软件的打包程序决定，尽管建议将程序包安装在/ opt //中，并且遵循与/ opt / packages准则类似的结构。偏离此结构的有效原因是支持程序包可能在/ opt // lib或/ opt // bin中安装了文件。

— 法赫姆·米莎（Faheem Mitha）
source

5

您只应使用/usr/local/share非特定于特定体系结构/操作系统版本的文件。

之后，由您决定是在的现有子目录之间分发文件，/usr/local还是在中创建新的专用目录/usr/local（但是在可执行文件中尚不存在后者）PATH，LD_LIBRARY_PATH，也没有MANPATH）。

看看FHS

— 豆
source

谢谢。因此，如果它是Windows的类比，它应该是/ usr / local / SPECIAL_APP，并且里面应该有它的子目录，对吗？

— greenoldman 2011年

@greenoldman：不。无类比将适合，因为Windows和Linux使用不同的模型：在Windows中，通常把所有的文件在一个单一的目录，在Linux中，你通常在其拆分bin，share，lib，等

— MestreLion

3

在/opt变得普遍之前，通常的地方是/usr/local/lib/<package>。

— 泰迪熊
source

1

据我了解，/ opt很普遍，只是没有被广泛使用，但是如果您想到存储库中可用的软件包数量，这并不是什么奇怪的事情。

— greenoldman 2011年

0

安装本地应用程序时，有多个选项，具体取决于您要访问和更新的方式。还应注意，有些方法看起来更像您已经拥有的系统，而有些则是临时的。我建议“最佳”解决方案是使事情更易于管理的解决方案。

我已根据要为其进行自定义安装的软件包数量来拆分此答案。分裂是基于我自己的经验。这些经验权衡了管理软件包所需的时间和弄乱某些东西的风险。我并不是说我具有通用标准的知识，而是要作为决策时参考的参考点。

对于仅有的几个软件包，我将把附加软件包放入/opt，在那里它们不会妨碍其他所有东西，因此没有东西可以弄乱它们，也可以弄乱其他东西。这是我在NAS上使用的方法。但是，此方法使二进制文件远离您的PATH，因此您将需要手动添加它们。如果只安装了很少的软件包，这将很好地工作，但是如果要安装的软件包太多，则将变得一团糟。

在这里更新非常容易，因为您只需覆盖目录即可。

优点：

简单
快速设置
没有机会影响系统的其他部分
卸载与安装一样容易

缺点：

如果要安装的软件包数量很大，将变得非常乏味
使PATH显得凌乱

对于多个软件包，我建议您使用/usr/local/<your package>或符号链接可执行文件，/usr/local/bin或者/usr/local/sbin根据您是否需要root特权来使用。这样可以避免您每次添加新内容时都更改PATH，从而使PATH保持干净。这是我在Arch笔记本电脑上用于所有非pacman软件包和AUR软件包的方法。

更新是通过覆盖软件包目录并检查符号链接是否仍然有效并修复（如果不是）来完成的。

优点

不会PATH凌乱
不影响基本系统
删除所有附加组件并返回到干净的基本系统仍然非常简单

缺点：

设置工作较多
仅删除一个软件包需要进行一些搜索

对于许多包。由于您并非如此，因此我将简要介绍一下。我建议拆分包入bin，lib，share等，将它们安装到/usr/local。这是为了保持结构清洁。您还可以指定可以在何处编写更多内容的人员。例如，您不希望除root之外的其他人修改可执行文件。

由于您需要写入多个目录，因此更新变得有些棘手。我建议打包整个东西，然后让打包管理器处理其余的事情。

股份

该share目录本身是体系结构无关的文件，如Faheem的注意环节和体系结构相关的文件应该去lib，lib32，lib64，等。

— 劳里·提斯里（LauriTšili）
source

根据软件包数量提供建议是没有用的；我怎么知道我的包裹属于哪个组？

— Alois Mahdal

另外，当您说“建议”时，请注明出处或明确指出这是您的建议（我猜是后者吗？？）

— Alois Mahdal

顺便说一句，我不知道在/ opt中出现什么事情比将其散布到/ usr等中的可能性要小。弄乱其他应用程序更多地是要正确地命名事物并且没有bug。安装脚本。

— Alois Mahdal 2015年

绝对是要使事情搞砸的命名。这是我过去所经历过的，这就是为什么我喜欢让我的“额外”包裹远离其他一切。我仍然不希望它看起来很丑。

— LauriTšili2015年

是的，您对“建议”是正确的，正如您从我的回答中看到的那样，我在其他地方都使用了“我会建议”。现在，我已修正拼写并清除了为什么我会推荐一些东西。再次，这只是我的观点，而不是一个明确的答案。

— LauriTšili15年