From: Paul H. Hargrove (PHHargrove_at_lbl_dot_gov)
Date: Wed Dec 19 2007 - 12:43:52 PST
Neal Becker wrote: > I am interested in packaging blcr for fedora/redhat. Since we last discussed > this, there have been some changes. Primarily, the main fedora/redhat repo > bans kmods. > > Instead, the kmods are packaged to the livna repository. They have written > some nice docs on this: > > http://rpmfusion.org/Packaging/KernelModules/Kmods1 > http://rpmfusion.org/Packaging/KernelModules/Kmods2 > > Previously, I have tried to build using dkms. This has the advantage of > automatically rebuilding when a new kernel is installed. It seems that there > is not widespread adoption of this, mainly because some environments might > not have needed build tools (e.g., embedded systems, compute clusters). > > I haven't yet studied the above docs, but I just wanted to get some feedback > from this list as to whether this looks like a good path to proceed on. > Thank you Neal, for continuing to pursue "main stream" distribution of BLCR. It is not an effort have time to devote to myself, but I recognize its value and appreciate that somebody else does too. I have read (briefly) the Kmods1 page, followed by the "main differences" section of Kmods2. My feeling is that the changes in packaging for BLCR will be less intrusive with this approach than was the case with the work Neal did previously to try to use dkms. It is important to me that users of BLCR still be able to build a full installation for their RPM-based system w/o need to install a bunch of recent tools/packages (like dkms, for instance) and that it work w/ a kernel that is not RPM packaged. I am happily using RedHat9 on my cluster and have no intention to replace the distro until it is time to replace the hardware - I am sure others have similar situations. I think the new kmods proposal sounds like it is probably an acceptable solution. Specifically, the kmods stuff goes in a separate specfile and .src and I expect that Provides: and Requires: lines will be the only changes to the portions of the BLCR specfile other than the sub-package for the kernel modules; and I believe that those can be done in a way that still allows the current method of building kernel modules. The kernel module binary packages built by the two methods (call them "kmod" and "legacy") will have distinct names to hopefully avoid confusion (kmod requires a specific naming that the legacy mechanism does not conform to, so distinct names is automatic). I think that if the kernel module sub-package in the BLCR specfile is disabled by default, then it should be suitable for inclusion in a Fedora/RedHat repo. That will add an extra rpmbuild argument or two for folks using the SRPM and a legacy kernel module build, but that seems acceptable to me. There are probably many small details that will come up when Neal begins actual work, but I think we can work though all of them. So, in principle I approve of this approach for BLCR. I reserve final judgment until I see it implemented, but if we can do this cleanly then I'll roll it into the BLCR CVS and try my best to maintain it. -Paul -- Paul H. Hargrove PHHargrove_at_lbl_dot_gov Future Technologies Group HPC Research Department Tel: +1-510-495-2352 Lawrence Berkeley National Laboratory Fax: +1-510-486-6900