CODEWITHSUNDEEP
linuxredhatrpm
Soid
Soid

Reputation: 2881

What is the process of recognition the RPM package latest version in RPM repository?

I'm just trying to figure out how RPM recognizes the latest version of some package. Say I have:

package-0.1-SNAPSHOT201212031
package-0.2-SNAPSHOT201212030

Will rpm manager compare it just as strings or there're some more logic behind it? Or another example: will it recognize that 0.10.1 is newer than 0.1.1? (string comparison wouldn't help here).

Upvotes: 0

Views: 287

Answers (2)

BenH
BenH

Reputation: 26

Old post, but I've been trying get this nailed down and thought I'd share what is working form me. I'm using a ruby script with an extension to the String class.

class String
  def explode
    self.split(/-|_|\./).collect {|i| if i == "0" || i.to_i > 0; then i = i.to_i; end; i}
  end
end

This breaks a given string into an array where a group of numbers are converted into a sortable numeric value (rather than being left as a string).

For example:

ruby -r./string_ext.rb -e ' puts %Q{package-0.1-SNAPSHOT201212031}.explode.inspect'
#=> ["package", 0, 1, "SNAPSHOT201212031"]

ruby -r./string_ext.rb -e ' puts %Q{package-0.2-SNAPSHOT201212031}.explode.inspect'
#=> ["package", 0, 2, "SNAPSHOT201212031"]

# the comparison of the resulting arrays is then very straight forward
ruby -r./string_ext.rb -e ' puts %Q{package-0.1-SNAPSHOT201212031}.explode <=> %Q{package-0.2-SNAPSHOT201212030}.explode'
#=> -1

Where -1 means that the first item is less than the second, 0 means they are equal, and 1 means that the second item is less than the first.

1 <=> 2 #=> -1
2 <=> 2 #=> 0
3 <=> 2 #=> 1

Using this approach it is pretty simple to collect the greatest value from an array of similar items (like an array of rpms associated with the same package).

Upvotes: 0

Jeff Sheffield
Jeff Sheffield

Reputation: 6316

The only hard and fast rule is there there can be no dashes in the RELEASE field.

Consider:

rpm -qi hwdata

followed by 

$ rpm -q hwdata --queryformat '%10{NAME} %20{VERSION} %20{RELEASE} %20{ARCH}\n'
hwdata             0.213.22                1.el5               noarch

See The Release Tag section of this doc for reference on the release tags rules.

Note: for reference, sometimes I programmatic-ly stuff things into the rpm description if there is no rpm-tag for it in the specfile. Your mileage may vary, and I am not recommending this for packages destine to be back in the community as it is awkward. Just pointing it out as a workaround to keep from braking the various tools that operate on rpm's.

Note2: it is a common practice to use revision-control numbers in the RELEASE field. While this breaks from the rpm convention a bit. ( modifying that field, implies that the specfile changed... not the contents) It is a handy field to use because it does not break any rpm tools, and provides you with direct reference to the contents version. Also... if you have rpm contents checked-into a revision control system, this is already stepping outside of the rpm model a bit anyway. I.E. source rpm's become unnecessary.

Upvotes: 1

Related Questions