[LU-4568] rpm -U always complains the installed package is newer

• Status: Resolved
• Project: Lustre
• Type: Bug
• Priority: Minor
• Reporter: Keith Mannthey (Inactive)
• Assignee: WC Triage
• Resolution: Low Priority
• Severity: 3

Description

When I install later version of any branch I see stuff like this:

# rpm -U lustre-2.5.0-3.0.101_0.8_lustre.g4fc5560_default_ga8809b3.x86_64.rpm lustre-modules-2.5.0-3.0.101_0.8_lustre.g4fc5560_default_ga8809b3.x86_64.rpm lustre-osd-ldiskfs-2.5.0-3.0.101_0.8_lustre.g4fc5560_default_ga8809b3.x86_64.rpm 
	package lustre-modules-2.5.0-3.0.101_0.8_lustre.g4fc5560_default_gaa63ee2.x86_64 (which is newer than lustre-modules-2.5.0-3.0.101_0.8_lustre.g4fc5560_default_ga8809b3.x86_64) is already installed
	package lustre-osd-ldiskfs-2.5.0-3.0.101_0.8_lustre.g4fc5560_default_gaa63ee2.x86_64 (which is newer than lustre-osd-ldiskfs-2.5.0-3.0.101_0.8_lustre.g4fc5560_default_ga8809b3.x86_64) is already installed
	package lustre-2.5.0-3.0.101_0.8_lustre.g4fc5560_default_gaa63ee2.x86_64 (which is newer than lustre-2.5.0-3.0.101_0.8_lustre.g4fc5560_default_ga8809b3.x86_64) is already installed

The installed version is not newer then the version I am trying to install (Master builds 3 days apart). Lustre builds later then another should install with a simple rpm -U .

Comments

[Joshua Kugler (Inactive)]

While we control the builders, we (TEI) do not control the build process. What RPM thinks is a newer or older package would depend on the RPM build process (most likely contained in lbuild and/or 'make rpm'). I think the developers would need to look in to this one.

[Andrea Garcia (Inactive)]

asking Andreas to take a look at this one to see if this should be an LU ticket instead.

[Andreas Dilger]

This is probably better as an LU ticket. I'm guessing that RPM is confused by the use of the git commit hash and thinks "gaa63ee2 > ga8809b3" means that the one is newer than the other. This is not a problem for actual release RPMs, because they do not contain the git commit hash as part of the version. When there is another release from b2_5 it will be numbered 2.5.1 and correctly be understood as newer than any 2.5.0-based build.

Probably the easiest way to fix this would be to increment the patch number like "2.5.0.n" where "n" is derived from the "git describe" count of patches after the 2.5.0 tag was made. That said, neither "aa63ee2" nor "a8809b3" are even committed to b2_5, but rather just builds from unlanded patches, so even the above mechanism would fail. It isn't practical to assign ordered builds to different branches on unrelated patches because one is not necessarily the superset of the other.

I'm thinking that this is just a consequence of using builds from unlanded patches.