Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rpmlib: Dependency sets (i.e. comparing RPM versions) #15

Closed
tony-iqlusion opened this issue Apr 8, 2018 · 1 comment
Closed

rpmlib: Dependency sets (i.e. comparing RPM versions) #15

tony-iqlusion opened this issue Apr 8, 2018 · 1 comment
Labels
good first issue Good for newcomers help wanted Extra attention is needed

Comments

@tony-iqlusion
Copy link
Member

tony-iqlusion commented Apr 8, 2018

This issue tracks support for using rpmlib to compare RPM versions, a.k.a. dependency sets. Presently no support is provided.

RPM has all sorts of complicated and fancy rules for comparing package versions and determining which ones are newer. Quoth the Fedora RPM Guide:

You could compare the version numbers directly, calling headerGetEntry to get the version and release tags, converting these strings to numbers and then comparing, but this would cause problems. The custom comparison is not as exact as the code in this section, especially since many packages have version numbers that are not true numbers, such as 1.12.4, with one too many decimal points. This makes the comparisons harder. In addition, there is more than just the version number to take into account. You need to deal with the Epoch value, as well as the release, too.

So, tl;dr: if we ever want to compare RPM versions, we should really use rpmlib's comparison logic to do it.


~~~We really gotta get #11 fixed!~~~

Update: #11 is fixed, and #19 added transaction set support.
@n3npq
Copy link

n3npq commented Apr 13, 2018

There are two levels of version comparison: rpmvercmp() and rpmds* dependency sets.

Note that rpmvercmp() needs to be applied to each element in the tuple (E,V,R) iteratively. rpmvercmp is NOT a means to compare two EVR strings.

The Python bindings are overly complex and encumbered with ancient politics having to do with the "mysterious epoch" and missing values, which you likely should avoid these days in new bindings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants