我在 RPM 打包中看到了一个有趣的模式。主库包将包括共享库本身：
/usr/lib64/libavcodec.so.54
-devel 包将提供标头和符号链接：
/usr/include/libavcodec/libavcodec.h
/usr/lib64/libavcodec.so -> /usr/lib64/libavcodec.so.54
为什么 libavcodec.so 符号链接是由 devel 包提供的，而不是仅仅包含在共享库包中？符号链接与开发人员想要的东西有什么关系？标头很有意义，但为什么要使用指向共享对象的符号链接呢？
答案1
发行版中的软件以一致的方式机械链接，并期望找到libavcodec.so.54，因此任何预构建的软件包都不需要未版本化的名称。
但是，如果您自己构建软件，则通常会使用-lavcodec或类似的软件，但它们会发现libavcodec.so未版本化。同样，构建脚本可能期望这些名称存在。
发行包不需要未版本化的名称，因此默认情况下不包含它们，但由于它们在构建其他软件时非常有用，因此它们包含在-devel包中。其他发行版有不同的描述，并将.so链接包含在主包中；两者都是合理的选择。
答案2
有不同的方法可以处理这个问题，但是，总的来说，如果您不使用自动化包管理，则不需要处理。实际上最多自动化包管理器所做的工作的一部分只是为了纠正由自动化包管理引起的问题。这并不意味着包管理器没有任何价值，只是意味着事后必要的过度修正所增加的价值代价高昂。
当你决定采用一种包管理方法时，你就将自己锁定了。你将 rootfs 的控制权交给了某个模式或另一个模式，从那时起你就必须接受它的怪癖，因为此后任何一个文件都可能是否与任何其他文件相互依赖，唯一了解的方法就是解开整个网络，直到您看到底部。
包管理器将网络编织在动态链接库线程之中、之中和之上。包管理解决方案通常非常依赖动态链接 - 如果整套应用程序可以获取相同的库，则包管理器可以更轻松地进行版本控制。因此，包管理器最大的不同之处在于它们处理动态库版本控制的各种策略 - 特别是在FHS环境，因为根树实际上是拼图中唯一的其他主要变量。您已经指出了这些典型的apt基于的之一图式s。