【问题标题】:Identifying most suitable dependent rpm packages识别最合适的依赖 rpm 包
【发布时间】:2017-12-11 11:09:50
【问题描述】:

不确定 SO 是问这个问题的最佳地点,但它与开发相关,所以也许有人可以提供帮助。

我编写了一个应用程序(在 python 中,但这并不重要),它解析 Yum 存储库数据库以整理 RPM 包及其依赖项。我遇到的问题是,当一个以上的依赖项满足时,我吸入了太多的包。

具体示例:我正在寻找满足 Java-1.8.0 依赖项的软件包列表,并获得 libjli.so()(64bit) 的依赖项。 libjli.so()(64bit) 我的代码正确地表明这是由 Java 1.8、1.7 和 1.6 流中的多个 -devel 包提供的。不幸的是,所有三个版本(及其依赖项)都包含在我的列表中。

我想我的问题是,给定满足要求的软件包列表,确定要包含的最合适的软件包的最佳方法是什么?即在解析 Java-1.8.0 的依赖项时,只包含 1.8.0 的 -devel 包,而不包含 1.6 和 1.7 的 -devel 包。

我知道这是我的代码的一个问题,我只是不确定 yum 生态系统提供了哪些工具来帮助我确定哪个包最适合从多个列表中包含。

【问题讨论】:

    标签: dependency-management rpm yum


    【解决方案1】:
    1. 不看你的代码就很难判断。

    2. 百胜死了。如果你正在开发新的东西,你应该在 DNF 之上进行开发。 DNF 使用 satsolver 算法(https://doc.opensuse.org/projects/satsolver/11.4/index.html),你可以使用 libdnf https://github.com/rpm-software-management/libdnf(以前称为 libhif,以前称为 libhawkey)。

    【讨论】:

    • 我已经取得了一些进展。我正在直接查询存储库托管的 SQLite 数据库,并意识到对于要求,我的查询返回了所有满足该要求的包。我想如果打包者没有指定版本,那么任何版本都应该可以工作,所以我通过简单地按包版本对查询结果进行排序并选择最高的来选择最新的。
    • 你提到 yum 已经死了。我知道这一点,但是使用 RHEL,这是我认为我将来需要考虑的事情。上游 repo 是否也在发生变化,还是会继续在后端使用相同的数据库结构?我提到了 yum repo 数据库,但我想我只是说 repo 数据库......
    • 尽管我讨厌问“你如何做 x”的问题,但至少自己没有尝试解决问题,它看起来像我的 c。 1000 行 python 大多是毫无意义的 - hawkeye 和 librepo 乍一看,就像他们做了我想做的一切。哦,好吧,我最初的目标是加速一个直接(并且缓慢)解析 RPM 文件的过程,我想我在这个过程中自学了一些 python
    • 是的,repo 结构(和 sqlite db)保持不变。
    • 我最终重构了代码以使用 libhawkey,我很欣赏它已被弃用,但它似乎是 RHEL 7(FC21?)中开箱即用的功能
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2019-12-30
    • 2020-01-03
    • 2021-07-05
    • 2021-05-01
    • 1970-01-01
    • 1970-01-01
    • 2011-08-12
    相关资源
    最近更新 更多