[LU-5614] use %kernel_module_package for weak-updates

• Type: Bug
• Resolution: Fixed
• Priority: Critical
• Fix Version/s: Lustre 2.9.0
• Labels: llnl patch
• Severity: 3
• Assignee: Minh Diep
• Reporter: Stephen Champion

Description

The correct way to support weak-updates in rpm packages is the vendor defined %kernel_Module_package. This does the right thing on all distributions.

We have used this feature in SGI Lustre for several years, and I plan to work this feature back into the master branch.

Issue Links

• is blocking: LU-7643 Remove kernel version string from Lustre release field
• is related to: LU-8343 build failures on SLES
• is related to: LU-8519 build is broken on sles12
• is related to: LU-8383 Wrong tests package dependencies
• is related to: LU-6677 Package lustre correctly for Fedora/RHEL
• is related to: LU-7722 Install/uninstall of Lustre RPMs is slow due to regenerating of initramfs
• is related to: LU-8377 lustre fail to build on el7
• is related to: LU-3956 Eliminate lbuild's nonstandard build process
• is related to: LU-3953 lustre build system improvments

Comments

[Cory Spitz]

FYI:
http://cdn.opensfs.org/wp-content/uploads/2016/04/LUG2016D1_Improved-Versioning_Morrone_DiNatale.pdf
https://www.youtube.com/watch?v=50VN9Q7BHYA&index=5&list=PLA5dHg1_l3V8r6eqrUnl8DiB-KH1K5yLH

[Minh Diep]

yes, a small fix for suse12 is in LU-8343

[Christopher Morrone (Inactive)]

The patch landed to master, so I closing this ticket. Good work everyone!

If there is any fallout that we need to work through, we can open new tickets for that.

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch http://review.whamcloud.com/12063/
Subject: LU-5614 build: use %kernel_module_package in rpm spec
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 3b7d27ea22faf1c6d0a37afa724fd9b5c3240322

[James A Simmons]

I discovered the kabi-whitelist issues with the following error during the build process:

Finding Provides: /usr/lib/rpm/redhat/find-provides
KERNEL ABI COMPATIBILITY WARNING
The kernel ABI reference files (provided by kabi-whitelists) were not found.
No compatibility check was performed. Please install the kABI reference files
and rebuild if you would like to verify compatibility with kernel ABI.

Finding Requires: /usr/lib/rpm/redhat/find-requires

Once I installed kabi-whitelish and the rpms started to work. Also 'rpm qp --release kmod-lustre*' prints out

kernel(__wake_up) = 0x642e54ac
kernel(add_wait_queue) = 0x650fb346
kernel(copy_from_user) = 0x3302b500
kernel(default_wake_function) = 0xffd5a395
kernel(kfree) = 0x037a0cba

So its working correct now.

[Christopher Morrone (Inactive)]

In reply to James from gerrit:

I don't modify any RHEL build scripts. Its a simple rpm extract source and build. Nothing fancy. Forcing people to require things like mock to just build client rpms is not going to go over well with sites.

No one is requiring special things like mock. We just require that, when building rpms, the prerequisite BuildRequires must actually be installed. This is a completely normal thing to expect in the rpm packaging world, and it is what all of the behind-the-scenes scripts from the distro assume will be the case. Most people will be able to meet that requirement, I think. To avoid installing the prerequisites, you have to replace system-provided behind-the-scenes scripts with your own. We did that for lbuild, despite how icky I felt doing it. . If you refuse to meet that simple, accepted requirement, you are free to hack up your own solution as well.

I just recommend mock for the places where you don't have access to a system where the BuildRequires are installed, or you don't have the permissions to install those packages. mock is designed exactly for those situations: it sets up a clean base chroot environment, and then installs only the packages required by the source rpm's BuildRequires.

If none of those things will work for people, they can always just download prebuilt binaries. The prebuilt binaries are going to work on a much wider set of kernels once they are no longer tied to one specific kernel version.

Yes, some adaptation of process will be necessary for some people. I know, change is hard. I totally feel your pain. The Lustre community has gotten very used to its oddball way of building and packaging. But that means that Lustre just flat out doesn't build through the standard tools of major distros like Fedora and RHEL. I think the advantage of supporting those standard methods vastly outweighs the short term pain we will feel as we adapt our personal processes to the new packaging methods.