新需求到手不要马上改，先厚着脸皮拖三天进度……反正三天后又变了

团队有 coding style 就拿出来怼他。没有……说个捷豹。

@coderluan 这位把话题递归扯到元异议，就变成一个没法继续下去的哲学话题了……

已故乔帮主说跟聪明人合作最大的好处是不需要顾忌对方的自尊心……

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

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

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

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

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

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

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

CSS 是没有层级的，有层级的是 DOM

把这些浮点和三角函数预先计算出来存成列试试？

这些也算软技能吗？明明都是硬梆梆的。

OO 大沙文主义终于在 JS 程序员圈也取得了胜利😄

建议你说服领导，把公司的操作系统环境统一，至少生产环境要统一，开发环境谁不愿意跟着走的要自己负责由此导致的兼容性问题。

就是说，你改好软件功能，测试通过了，要打包了，假设你公司的生产和开发环境使用以下发行版+版本，那……
拉起一个 centos 8 （或者 alma 8 、rocky 8 、龙蜥 8 ）的 docker ，在里面打出 -el8 的 rpm 包；
拉起一个 centos 7 的 docker ，在里面打出 -el7 的 rpm 包；
拉起一个 debian 11 的 docker ，在里面打出 -bullseys 的 deb 包；
拉起一个 ubuntu 20.04 的 docker ，在里面打出 -focal 的 deb 包。
把这 4 次拉起 docker 写成一个批处理脚本自动跑完就好。

@liuguangxuan 不清楚用 cmake 如何自动识别发行版再打包……但正常的做法是，当软件出新版之后，用批处理流程为支持的每个发行版+版本组合自动起相应的 docker ，在 docker 里面打包。可以参考有个开源 API 网关叫 APISIX 的 build 系统 apisix-build-tools ，使用时可以通过参数指定包格式、发行版、版本号，只要自己写一个脚本来批量多次调用打包工具就行了。

@liuguangxuan Linux 的软件安装是个很复杂的生态。可以不管发行版，自己从上游软件的源代码开始编译安装，也可以不用管 File System Hierachy 规定的什么文件放在什么目录……实际上大部分上游软件编译之前的 configure 或类似阶段的默认值就是不遵循 FSH 的。但有发行版在，对于普通用户节省了挑选上游软件具体版本测试其搭配的兼容性的精力。

同时，发行版会在自己编译开源软件时做一些风格上的适配，比如约定不同类别的文件放在什么路径、后台服务程序用什么机制启动、配置文件如何细分到各种**.d 里以便把插件的配置和主配置分开方便自动修改、日志文件如何定时切分，等等。

rpm 和 deb 是两大主流发行版 RH 系和 Debian 系的“御用”格式，发行版本身包含的组件（比如 Debian 当前版本里有 8 万多个软件）是用这两种格式来打包的。通常比起上游来经过了一系列统一风格的改造。理论上是可以跨越发行版混装的，但实际上有很多问题，有些能装成功有些则不行。所以正常的做法是，写好 spec/rules 然后针对用到的特定目标发行版和目标版本来做自动打包，当然 spec/rules 是有兼容性问题的，也要好好适配同一发行版的不同版本。你厂 IT 基建环境基本为 0 的话而你又要兼作基建的话，那强烈建议现阶段尽量减少发行版 /版本的数量。比如都统一到 Debian 或者 CentOS 的一两个版本上。暂时统一不上去的，以后逐步改版替换。操作系统版本迭代导致的屎山，等以后再去想办法治理，现阶段既然是 0 ，还是尽量简化。

还有很多开源软件（有的闭源软件也是），是发行版不会包含或者还没收录的，上游作者有时候也会打包成 rpm 或者 deb ，让用户能以使用发行版的相同操作风格来管理。甚至有些体积很大的，比如 GitLab ，比如 Elastic Search 。

但是打包 rpm 或 deb 往往是个吃力不讨好的事，因为很多人（尤其是纯开发角色的）其实不太在乎运维方面的讲究，他们更喜欢一个 tar.gz 原地解压后的 everything-under-prefix 方式，认为这样更方便和自由，而 rpm 或 deb 里遵循 FHS 等规范的生产环境打包方式对开发来说太麻烦了，比如要考虑各种路径的权限、执行时的用户身份等，而且“散落”在不同的地方，开发过程中查找起来麻烦，等等。在企业里，基建团队打包 rpm/deb 是不产生直接的业务绩效的，开发团队对这些玩意的认可度也不高。所以往往会有企业根据自己踩过的各种坑自己搞得各种“最佳实践”。其实长线下来 rpm/deb 的学习成本未必高，但是起点高，要学一大堆不能马上产生绩效的“乱七八糟”的东西，而且很可能不讨大部分开发人员喜欢。所以大部分厂的业务型软件都不太用发行版包的方式来发布。

所以，虽然我自己（一个甲方的综合信息化人员）比较喜欢按发行版打包、按 FHS 布局的行为，但在这贴里还是建议你慎重考虑。因为精力投入会比较大，不产生业务绩效，而且不太容易被其他人接受。看看这贴里的很多回复就知道了。当然，如果你觉得值得，自己能 hold 住，说不定会成为业界尤其是国内业界与众不同的一股清流（ or 泥石流）。


另外，还有值得一提的是，发行版的打包方式，其实是很传统的了。在云原生时代，很多软件对于外部依赖组件所采取的 vendoring 策略跟发行版打包是矛盾的。Debian packaging team 曾经尝试把 K8S 给 deb 化，但 K8S 特定版本和 Debian 特定版本的第三方依赖锁定版本冲突，始终没办法很好解决，最后终于放弃。LWN 上还曾经专门有一篇讨论。最后的结论是，三观不同没法强融。

虽然版本不行 => 虽然版本不同

对了，OP 你为啥执着于检测发行版？而且你所谓的检测发行版是在打包时检测，还是装包时检测，还是运行时检测？

打单个包兼容多种发行版还是不太现实的，不是社区的常规做法。一般是针对不同发行版、不同版本单独打包。可以在独立的目标版本机上打，也可以临时拉一个 docker 进去打。虽然版本不行，但 rpm spec 或者 debian rules 未必不同（当然，而已有可能不同），不同的是打出来的包的依赖而已。

另外还想问一下 OP ，你打包的目的到底是啥，你在公司里是什么角色，公司的 IT 基建环境怎么样……如果是纯开发的话，自己去想打包问题可能会有点累又自作多情，还是跟基建组的同事商量一下吧。