我正在开发一个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中报告的行为: