我正在以非根用户身份从源代码构建几个(> 10)包,并希望安装它们(为了解决这个问题,请选择值--prefix=
)。两个明显的选择是:
- 使用我的主目录,这意味着我将拥有
etc/
、usr/
和var/
类似的子目录,并且每个子目录中都将包含不同包的文件。但大多数软件包都不会交互,因此将它们的文件放在同一个子目录中没有多大意义,我认为这会让卸载变得很痛苦 - 为每个包使用单独的目录,例如
--prefix=$HOME/myfooapp
,--prefix=$HOME/mybarlib
等等。这将使所有内容保持独立,但现在我的主目录将充满多个我不想看到的子目录。另外还有一些套餐做交互,所以我不介意它们在同一个地方在一起(不需要使 PATH 超长)。
我还缺少其他选择吗?我的意思是,我可以做
- 与选项 2 类似,但位于我的主目录的子目录中,例如
--prefix=$HOME/opt/myfooapp
,--prefix=$HOME/opt/mybarlib
这是我能做的最好的事情吗?
答案1
我认为这通常是一种网站惯例。对于长时间运行的安装,我不愿意依赖 $HOME 树,而更倾向于使用 /opt,即使这意味着使用适当的权限和可能相关的目录来设置 /opt// 以用作数据等的标准位置与您可以指出的某些事物的合理解释相一致,例如https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
对我来说,除了尽量不直接违反惯例之外,对结构的使用影响最大的是服务器的使用。您是否打算将服务器映像替换为不同的环境或软件/数据?您是否使用共享文件系统或需要特定分区来优化软件?您想将这些目录包含在任何备份等中吗?您想与其他用户帐户共享执行权限或数据吗?您可能还需要考虑在共享 shell 配置文件登录中设置某些环境变量,以扩展默认路径和常用的构建标志。
希望这能给人一些深思。当然,如果在本地计算机上,则执行感觉正确的操作,但不要排除使用 /opt,因为这是被忽略的目录树;^)
答案2
最终我决定$HOME/opt/myfooapp
。原因是:
- 选项 2 和 3 允许我分离不同包的文件层次结构;当您以 root 用户身份使用 / 时,这不太需要考虑 - 因为您有一个包管理器可以帮助您。我不...
- 只有选项 3 可以避免我的主目录因与软件包安装有关的多个目录而变得混乱。
答案3
我使用--prefix=$HOME
.更少的混乱PATH
(以及其他类似MANPATH
甚至信息文件位置),并且编写得当的包无论如何都不会踩到各自的脚趾。