BLCR Debian Packages

From: Alan Woodland (alan.woodland_at_gmail_dot_com)
Date: Thu Jul 23 2009 - 03:36:57 PDT

  • Next message: Neal Becker: "Re: BLCR Debian Packages"
    Hi,
    
    A Debian user has requested packages of BLCR.
    (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=529619)
    
    As a BLCR user and Debian developer, with a vested interest in seeing
    BLCR packages I thought I'd give it a go myself (I hope that's ok with
    you?). I'm in the process of packaging things, but I've got a few
    questions/issues I'd like to check up on:
    
    1) Are the userspace parts (library, utilities and development
    headers) are independent of the running kernel version? They only
    depend upon a kernel module of the same BLCR version for the current
    running kernel correct? The package structure that fits best with the
    Debian way is to make libcr0, libcr-dev blcr-util, blcr-source (and on
    amd64 lib32cr0), as well as blcr-modules-KERNEL appropriate to the
    release. To build all the userspace bits I'm currently configuring
    with the '--with-installed-modules' option.
    
    2) To build the blcr-modules-KERNEL the ideal solution would be to use
    module assistant (this means that even on custom kernels users could
    type 'm-a a-i blcr' and get a working kernel module automagicaly built
    for them. In order to do this there needs to be a cut down source
    tarball built, which lives inside the blcr-source package that can
    build the kernel modules for a given kernel. At the moment I'm just
    re-taring the whole of the BLCR source tree for this and then making
    module assistant call the whole configure script again, with
    --with-installed-libcr --with-installed-util --with-components=modules
    so that it only builds the kernel modules. Is there a nicer way of
    going about this? The configure script is obviously critical here, but
    can you suggest a nice way of trimming things down? Most modules seem
    to end up just shipping *.c and *.h required for the kernel module in
    this, along with a paired down makefile. I did wonder about moving the
    kernel space bits into a sub-tree and having configure call configure
    on a subdirectory, but that's a pretty substantial patch.
    
    Does this sound reasonable? Would someone be willing to test (and
    review?) this for me? I'd very much like to see BLCR in Debian, but I
    don't want to end up acting unilaterally!
    
    Thanks,
    Alan
    

  • Next message: Neal Becker: "Re: BLCR Debian Packages"