0

Maybe this question is a bit weirded but I am struggling here.

By what criteria does rpm determine that a packet is an update or not?

The version and release is a string and so on it cannot be compared to other versions. There are three flags to define a version: epoch, version and release. Is rpm (and yum, dnf, ...) checking the build time to determine if a package is an update? I can't barely believe this but I cannot figure out anything else.

I am not skilled enough to find the location of this feature in the source code by myself. Maybe someone can help.

Thank you very much.

3

RPM packages have a specific format: [$epoch:]$name-$version-$release.$arch

The $epoch is an integer that can be easily compared, there are packages that do not use this and it is just omitted. $name is simply a string that should not change between versions. $version is a version string in a format which can be parsed and compared (usually integers separated by periods). $release is a string that normally begins with an integer, but can also contain information about what distribution it was built for.

If all of $epoch, $name, and $verion are the same, then $release is compared to determine if it is an update. If the $versions are different, they are parsed and the higher one is the update. If the $epoch is different, the higher one is the update.

The source code for RPM update comparisons I believe can be found here in the functions parseEVR and rpmdsCompareEVR.

| improve this answer | |
  • Nice explanation. The version doesn’t have to be “semantic” (semantic versioning is more about the contents of releases and how the next version is determined, than the structure of the version number anyway), but the numbers it contains are period-separated — so the comparison is more generic than major.minor.patch but works for that case too. For example 20200320 is a valid version. There’s a detailed spec somewhere in the RPM documentation... – Stephen Kitt Mar 20 at 7:51
  • There is a devel tool to easily test the comparison: rpmdev-vercmp 1.2 1a.b gives 1.2 > 1a.b – msuchy Mar 20 at 12:33
  • I removed the reference to semantic versioning and made it more generic. – GracefulRestart Mar 20 at 19:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.