https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-4568 Lustre <p>When I install later version of any branch I see stuff like this:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre># 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 </pre> </div></div> <p>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 .</p> LU-4568

rpm -U always complains the installed package is newer

Bug Minor Resolved Low Priority WC Triage Keith Mannthey Thu, 30 Jan 2014 21:48:00 +0000 Sat, 9 Oct 2021 05:58:24 +0000 Sat, 9 Oct 2021 05:58:24 +0000 0 4 <p>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.</p> <p>asking Andreas to take a look at this one to see if this should be an LU ticket instead.</p> <p>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 &gt; 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.</p> <p>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.</p> <p>I'm thinking that this is just a consequence of using builds from unlanded patches.</p> Development Rank 1|hzwdxz: Rank (Obsolete) 12468 Severity