关于 Linux 下面的 包管理器的 疑惑

[huyangq]

linux 的包管理器很强大 下载软件十分的方便 但是下载的软件各个目录 好像是分散在 各个目录中的，比如下载了 redis 启动程序 好像在 /usr/bin 中 数据好像在 /usr/local/redis-3.2.0/data 为啥 要这种设计呢？ 直接在一个固定的目录下面不行吗？

[kujio]

bin 里存放可执行文件
local 存放缓存数据
很合理啊。

[richangfan]

约定俗成，`/usr/bin`放系统软件，`/usr/local/bin`放用户软件

[seers]

linux fhs

[ration]

你放在一个目录，那你只能到目录里启动程序了。如同 windows 下也要配置环境变量，路径之类的

[iamzuoxinyu]

Unix 规范。现在有了 snap/flatpack 之类的容器化的打包方式，可以将一个应用的资源全部放在一块。

[masterclock]

这东西大概是 1969 年发明的，甚至早于创世纪，很难修改了

[SaltyKitkat]

根据 fhs 约定来如此安排的
好处是从某种角度的方便
头文件在 /usr/include
可执行文件在 /bin, /sbin, /usr/bin, /usr/sbin
动态链接库在 /lib, /usr/lib
可以免得安装一个库之后，其他依赖这个库的软件发生“找不到 libxxx.so”错误，还需要手动配置各种环境变量啥的

坏处就是像你说的，一个软件包安装之后就变成“散装”的了，各个文件散布在不同地方，包管理器需要记录每个软件包和它的文件的对应关系才能工作

至于你的想法“直接在一个固定的目录下面不行吗？”
当然行啊，只不过不符合一直以来比较主流的约定罢了
比如 NixOS 这个发行版，就可以认为是把每个软件都安装在 /nix/store 路径下面一个“固定的目录”里面（当然实际情况要比这复杂得多）

[adoal]

我见过很多不做运维的纯开发人员都对 FHS 困惑和反感😄

https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

[adoal]

把文件按作用分类到不同目录，而不是按业务领域，有些可能的好处。因为通常文件在文件系统里的权限、性能、易变性是按作用而不是按业务领域来划分的。

比如[/usr]/[bin|sbin]下的可执行程序、[/usr]/lib 下的动态链接库，/usr/share 下的静态数据，通常不需要普通用户有写入权限；/var/lib 下的数据库、/var/log 下的日志通常需要各自的 uid 有写入权限；/etc 下的配置通常在程序和数据做小版本升级时不需要改动，但管理员可能要单独修改；/run 下的 pid 、socket 最好在系统重启后就没了，以免判断错误。等等。
再比如，在资源受限的环境（比如路由器），可执行程序和不可变数据可以做成只读的压缩文件系统，启动后部分解到内存或者按需解开；配置文件需要改变后持久化到闪存；日志通常不需要持久保留。

按 FHS 划分就很容易为不同业务功能但相同作用的文件设置统一的存储策略。而按业务领域划分，从这个角度看反而是散乱的。

[adoal]

RPM 系和 DEB 系主流发行版里打包好的包都是按 FHS 来。

而单位自用业务系统里的业务功能部分，不论是搞外包的传统行业的信息化还是自养开发团队的互联网，普遍倾向于按业务领域划分，everything-under-business-prefix……

[huyangq]

哦哦 那问题来了 假如我在启动的时候 需要改一下配置文件 比如我改一下端口号 那还得找 那多麻烦啊

[huyangq]

@adoal 鱼跟熊掌不可兼得 有点理解了

[libook]

FHS 是个通用标准，大家尽量按照统一标准来做。

放独立目录也不是不可以，比如自己编译的一些软件可能会放在 opt 目录下，但你就得自己搞定环境变量啥的，不像统一放在 bin 、lib 目录下有统一的环境变量可以用。

[yohole]

不懂就问：macos 现在安装的软件是不是就放在一个文件中，卸载其实就是直接把这个文件删除掉？

[iamzuoxinyu]

@yohole 有一些其实就是个 xxx.app 文件夹，运行的依赖都在里面，常见于纯 GUI app 。cli app ，其实也大体遵从这个规范的。

[libook]

@huyangq #11 配置文件通常统一放在 etc 下面，很好找的，惯例也是只动这个目录下的配置文件，其他目录的作为默认配置被覆盖。

[libook]

@yohole #14 macos 安装软件分两种，一种是跑在苹果自己的应用框架下的应用程序，统一放在 Applications 里；另一种是 Unix 程序，也会放在 FHS 结构里。

[andyhuzhill]

@huyangq 都按照 FHS 标准的话 配置文件都在 /etc 目录下了 很好找啊

[libook]

@yohole #14 其实 Linux 也有类似 macos 的方案，比如 snap 应用，可以了解一下。

[SenLief]

linux 也有 snap 这种放在一起的。FHS 的标准好处是，你想要修改配置文件理论应该在 /etc/app/下面。

[huiyifyj]

这些都还好吧，因为 FHS 标准如此。
但是 FHS 标准有些时候挺抓狂的，尤其是 opt 的文件夹，就没几个开发喜欢放那

[westoy]

你这个会把数据放 /usr/local/redis-3.2.0/data 下面的不像什么正经的包管理啊

/usr/local 一般官方的包管理不会去碰的， 数据是放 /var/lib/XXXX 下面的

[Huelse]

如果不遵守约定或不知道应该怎么放，就放在自己用户目录下吧 ~/

[Buges]

因为这种目录结构能集成。比如一个应用的本体可执行文件可以直接在终端运行，那就放到 /usr/bin 里。如果给其他程序提供库，那就放到 /usr/lib 里。如果要添加文件关联，直接放到 /usr/share/applications 里。配置文件统一放在 /etc ，数据在 /var/lib/appname 等等。比 Windows 注册表那样添加一堆莫名其妙的东西卸载了还删不干净好吧。

[lolizeppelin]

window 闭源都不共享内容,自然都是自己东西全放自己文件夹完事也不需要什么规范,也就是大家最喜欢的绿色模式

linux 是个开源共享的系统,共享意思是你可以用我东西我也可以用你东西,为了方便共享大家有统一规范

非共享的情况软件自己管好自己一亩三分地就可以,没有依赖也不需要依赖管理,因为别人和你没关系
共享就要遵守统一规则否则依赖混乱,你自己变更还要考虑到别人的兼容

[whenov]

可以关注下 GoboLinux ，根目录结构为：
Depot Mount System Files Programs Users

[baobao1270]

题主说的不对，要么是 /usr/bin 放程序、/var 放数据；要么放 /usr/local/bin 、/usr/local/var
如果用包管理器，几乎不会用到 /usr/local ，如果遇到了说明打包者没有打包好（编译时设置了错误的 prefix 选项）

这个标准叫做 FHS 。其实 FHS 这个东西也有点过时了，现在很多发行版都在作 USR Merge （只保留 /usr /etc /var ，/bin 、/sbin 、/lib 都是软连接）

FHS 确实有很多优点，但是在某些场景也有一些不太令人满意的地方。我感觉最好是单开一个 /app 目录，然后设置 /app/something/bin 、/app/something/lib 、/app/something/etc ，然后软连接到 /usr/bin 、/usr/lib/something 、/etc/something 。

[codehz]

主要的问题是为了使用共享库，而为了使用共享库，必然就得有公共路径，这样一来，单独给程序放独立文件夹的意义就少很多了 - 你还得考虑统一性吧，总不能一些文件在独立目录，一些文件又在公共路径
你单独发布的软件可以把需要的 so 全部打包在一起，发行版还这么干，那里面得有多少重复文件啊（ nix 等另辟蹊径的暂且不提）