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-7976 Lustre <p>It now appears that the recent landing of the mod for "<a href="https://jira.whamcloud.com/browse/LU-7699" title="Overhaul lustre&#39;s versioning" class="issue-link" data-issue-key="LU-7699"><del>LU-7699</del></a> build: Replace version_tag.pl with LUSTRE-VERSION-GEN" has had bad side effects on build and test for any sles version. Bad effects have been seen in both sles11sp3 and sles11sp4.</p> <p>One effect is lustre-osd-ldiskfs-mount no longer gets installed automatically. The requires string in lustre-osd-ldiskfs doesn't match the provides string in lustre-osd-ldiskfs-mount.</p> <p>lustre-osd-ldiskfs-mount provides says:<br/> lustre-osd-ldiskfs-mount = 2.8.51_3_g8062fbb-3.0.101_71_lustre_default</p> <p>lustre-osd-ldiskfs requires says:<br/> lustre-osd-ldiskfs-mount = 2.8.51_3_g8062fbb</p> <p>They don't match. Before the landing of <a href="https://jira.whamcloud.com/browse/LU-7699" title="Overhaul lustre&#39;s versioning" class="issue-link" data-issue-key="LU-7699"><del>LU-7699</del></a>, they did match.</p> <p>rpm names now are inconsistent in any sles build. some examples:</p> <p>lustre-modules-2.8.51_3_g8062fbb-3.0.101_71_lustre_default<br/> kernel-default-3.0.101-71_lustre</p> <p>lustre rpms have '3.0.101_71_lustre_default" in the name<br/> kernel rpms have "3.0.101-71_lustre" in the name</p> <p>some or all of these unexpected side effects of the name changes block our normal automatic build/test flow on any SLES versions.</p> LU-7976

sles builds severely impacted by recent naming changes

Bug Critical Resolved Not a Bug Bob Glossman Bob Glossman Fri, 1 Apr 2016 18:29:33 +0000 Thu, 14 Apr 2016 14:58:43 +0000 Thu, 14 Apr 2016 14:58:43 +0000 0 4 <blockquote> <p>lustre-osd-ldiskfs-mount provides says:<br/> lustre-osd-ldiskfs-mount = 2.8.51_3_g8062fbb-3.0.101_71_lustre_default</p> <p>lustre-osd-ldiskfs requires says:<br/> lustre-osd-ldiskfs-mount = 2.8.51_3_g8062fbb</p></blockquote> <p>What did they look like previously? It is not immediately obvious to me that these are actually mismatched. The one package requires a particular Version, and the other provides said Version. Granted, the "Provides" includes the Release as well, but as far as I know that should not break Version matching.</p> <p>The patch did not directly change the Provides or Requires for those patches, either. There was indirect change because the git describe information moved from the Release to the version. But it would not have changed the fact that one Provides Version-Release, and the other just Requires Version.</p> <p>I'm a little confused about what has actually gone wrong. Can you please post the explicit errors that you are seeing?</p> <blockquote> <p>rpm names now are inconsistent in any sles build. some examples:</p> <p>lustre-modules-2.8.51_3_g8062fbb-3.0.101_71_lustre_default<br/> kernel-default-3.0.101-71_lustre</p> <p>lustre rpms have '3.0.101_71_lustre_default" in the name<br/> kernel rpms have "3.0.101-71_lustre" in the name</p></blockquote> <p>Can you provide a longer list of the employed sles kernel packages? "rpm -qi" on the main package would also be helpful.</p> <p>It is not immediately clear to me how the "default" string is jumping out of the kernel package name and landing at the end of Lustre's Release field. I don't remember writing any special code to do that. It seems more likely that the kernel really does have "-default" in its version somewhere.</p> <p>Chris,<br/> i think the idea about provides/requires strings not matching is a red herring. It now seems more likely that the sles provisioning problems we've been observing lately are not due to the naming changes in package names or versions, but to other recent build changes.</p> <p>Once I know for sure it's likely this bug will be closed out.</p> <p>OK, then I won't look into this further for now. If you later find out that it is related to the version changes, just let me know. I'm happy to keep working on it until we find something that works well enough everywhere we need it.</p> <p>The actual build problem isn't at all the one imagined and described here. Closing this bug. See <a href="https://jira.whamcloud.com/browse/LU-8023" title="build problem on master due to recent change" class="issue-link" data-issue-key="LU-8023"><del>LU-8023</del></a> for the real problem.</p> Related LU-7699 Development Rank 1|hzy6nb: Rank (Obsolete) 9223372036854775807 Severity