[LUDOC-124] A question of kernel debuginfo rpms

• Type: Improvement
• Resolution: Unresolved
• Priority: Minor
• Assignee: Lustre Manual Triage
• Reporter: Keith Mannthey (Inactive)

Description

So I use the basic instructions on the wiki for building locally. So far it has worked well for me until...

I needed kernel debuginfo rpms built and ZFS.

These rpms greatly simplify debugging and profiling. Several common tool utilize this data.

Our build server via the lbuild procedure we get 30 some odd packages including zfs and most of the debuginfo you could want.

Also LU-2662 shows that building local and lbuild are two different things.

In general it would be nice to have lbuild documentation.

Comments

[Christopher Morrone (Inactive)]

It kind of looks like the entire chapter needs work. Rather than clog this ticket, I started LUDOC-224 with some review comments.

[Richard Henwood (Inactive)]

The manual reciently received an update on the Building Source section:

http://build.whamcloud.com/job/lustre-manual/lastSuccessfulBuild/artifact/lustre_manual.xhtml#installinglustrefromsourcecode

I believe the source material here is the wiki page - neither of which describe using lbuild.

My preference is to remove 'document lbuild' from this ticket and remain focused on enhancing the documentation to show how to get debug info from the 'make rpm' route.

[Keith Mannthey (Inactive)]

It has been about a year so I don't think Lbuild is going into the Lustre Manual in time soon. In the last year I have learn to use lbuild a bit and I agree lbuild is it own 1 off thing.

[Christopher Morrone (Inactive)]

I would argue that lbuild is Intel's historic and obsolete method for building. It is by no means the proper way way of building anything. There are many things that it does that a proper build and packaging system should not.

For instance, rather than properly expressing and testing rpm build dependencies, lbuild invents its own way to install dependencies, and manually cpio unpacks binary rpms. That is just horrible. No one should follow that example.

I entirely agree that there should be good build documentation, but we should document good procedures, not lbuild's methods.

[Keith Mannthey (Inactive)]

I noticed with Lustre 2.5 "make rpms" is making a larger set of packages.

[Jessica A. Popp (Inactive)]

reassigning to Jodi so that it goes through triage

[Keith Mannthey (Inactive)]

I would like to reframe this as basic Lbuild instructions are needed in a public spot.

Lbuild is hard to use but is the proper way to build lustre. As an opensource project Building the code is an important part of the life cycle.