I'm a developer on the Lustre project @ Sun.  I have been maintaining a
local patch to create a /debian subdir for our Lustre tree.  Currently
my /debian work is based on an implementation by Alastair McKinstry but
has probably diverged from there a bit.

I want to get some form of .deb building committed into our tree and as
such have bug 19721 open on our bugzilla with my patch and some

Currently, my patch only builds a patchless client and is based on our
1.8.1 development release for Ubuntu's Intrepid 2.6.27-11 kernel.  I am
hoping for some review of my patch by people familiar with Debian
packaging and thought you folks would be a great place to turn to.

I have become aware of the pkg-lustre project through this effort but I
have a feeling our goals, while generally the same, take different
paths.  In looking at your debian/rules, I see your and my origins are
the same and I tried to remain on that path but I was not successful in
meeting our goals with it.

The biggest issue I had/have is the use of module-assistant to build the
kernel modules.  While I generally agree with that approach, I found it
unworkable given that my desire is to run:

$ dpkg-buildpackage

(note the $ signifying an unprivileged account) in a lustre source tree
and have all required packages produced, including the
lustre[-client]-modules package.  I could not find a way to do this with
m-a that did not at some point require root privileges.

Also note that this needs to be achievable in a manner that does not
require one to have the machine that runs the dpkg-buildpackage be
booted on the target kernel.  i.e. the build needs to be optionally
directable to the kernel-{source|headers} against which to build the

At this point, I'd be happy enough to just have patchless client
packaging functioning.  If we can get patched server builds integrated
as well, well, that's welcome gravy.



Attachment: signature.asc
Description: This is a digitally signed message part

Pkg-lustre-maintainers mailing list

Reply via email to