我正在开发一个Java项目，每个模块创建的单个rpm包始终具有 1.0 版本标记，但Release标记采用Jenkins CI注入的内部版本号。
每个组件都使用maven-rpm-plugin。
还有一个主 rpm包，我们在规范文件中指定已部署模块的确切版本作为要求，作为一个要求示例：
要求：module1 = 1.0-10
要求：module2 = 1.0-123
软件包已部署到公司的存储库中，并可供运行CentOS 6的开发机器使用。
所以问题是：
在一台开发计算机上，安装了以前的主软件包 module1-1.0-9
当我使用yum安装当前主软件包版本时，即使我指定了完全软件包版本要求，module1 也无法升级 ，直到Release标签。
删除所有软件包并尝试安装当前主软件包后， module1-1.0-12 安装完毕！在此期间部署了另一个模块构建。
我一直在寻找有关此问题的任何文件，但没有任何运气。
这是正常行为还是错误？
有什么想法吗？ - 即使更改版本控制策略也会受到欢迎，如果它确实不是错误的话。
答案 0 :(得分：0)
包名是否以某种方式改变？ Yum使用名称，版本和版本。因此，如果您使用不同的名称打包，那么yum将不会将较新的包视为旧包的更新。
执行rpm -qip *your-rpm-file-name.rpm*并比较名称的输出。我在过去看到有些人对RPM的文件名和yum / rpm使用的RPM的实际名称感到困惑。
答案 1 :(得分：0)
又过了一天，我终于在bugzilla中偶然发现了这个错误报告。
我还看了一下与yum相关的source code并找到了对 depsolve.py 模块的评论，该模块解释了如何解析依赖关系并证实以前在CentOS 6中报告的行为：