Bug#529619: Fwd: BLCR Debian Packages
Forgot to CC the ITP bug...
---------- Forwarded message ----------
From: Alan Woodland <alan.woodland@gmail.com>
Date: 2009/7/23
Subject: BLCR Debian Packages
To: "checkpoint@lbl.gov" <checkpoint@lbl.gov>
Cc: Alan Woodland <awoodland@debian.org>
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
Reply to: