Re: blcr fedora kmod (try again)

From: Paul H. Hargrove (PHHargrove_at_lbl_dot_gov)
Date: Wed Dec 19 2007 - 12:43:52 PST

  • Next message: Yuan Tang: "Re: BLCR 0.6.2 beta1 now available"
    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:
    > 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 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

  • Next message: Yuan Tang: "Re: BLCR 0.6.2 beta1 now available"