Re: Building a kernel-source RPM (not a kernel RPM)?

[Bernd Petrovitsch]

On Wed, 2007-09-12 at 10:31 -0700, Dan Stromberg wrote:
> On Wed, 12 Sep 2007 19:09:26 +0200, Bernd Petrovitsch wrote:
[...]
> >> I'm on a SuSE system.
> >> 
> >> I'm working on automating the install of said system, but it needs a
> >> Linus kernel - 2.6.21.7 specifically, and it needs kernel source too so
> >> that we can build modules in the field as needed.
> > 
> > Find a kernel-source.*.src.rpm or kernel-*.src.rpm or whatever SuSE uses
> > for
> > nameing convention and reverse engineer the .spec file.
> > Fedora BTW abandoned kernel-source* and they have now a website with a
> > description
> > how to produce a configured kernel source tree (e.g. for out-of-tree
> > modules).
> 
> So this is as smooth as producing kernel-source RPM's gets?

I had no problems with the kernel-source.*.rpm approach.

> I might be better off sticking with a .tar.bz2 and repointing symlinks.
> 
> >> I see you can make an rpm of a bootable kernel with "make rpm".
> > 
> > Well, then there must be a .spec file somewhere which just wants to be
> > extended.
> 
> I'm not sure this is going to be any easier to automate, if that's what's
> required.

The problem, that automation of such a task depend on various factors
(which
may be somewhat private):
- you have a linux-$VERSION:tar.bz2
- optionally, you have patches. And some distributions have *lots* of.
- you need a .config (and run `make oldconfig`).
You have to decide on each (independent if you build an RPM or a script)
of
them.
If you need regularly .rpm from ongoing development, you probably need
to figure out first which procedure is the best.
It's from a conceptual view different if you either have your kernel
source
and produce new kernels every other day for testing, etc. (then simple
scripts
are more than enough) or you produce a .rpm every other day to install
it and
keep it for months (for whatever reason).

[...]
> I may just stick them in a bash script and forget about the RPM.  Or are

A .spec file is a just set of "scripts", some meta-information and
produces
a container. And you have a package management at install time.
I can't decide if the more effort for the .rpm pays off for you - that
also
depends on factors like "geek value", "number of installations", ....
And that the reason for me to suggest to find a recent SuSEs
kernel.src.rpm
and start from there or find the one behind the "make rpm" thingy.

[....]
> On OpenSuSE 10.2, there appears to be:
> 
> # find / /home -xdev -ls | egrep -- '-> /usr/src/linux'
> 215641    0 lrwxrwxrwx   1 root     root           26 Sep 11 17:50 /lib/modules/2.6.18.2-34-default/source -> /usr/src/linux-2.6.18.2-34
> 213786    0 lrwxrwxrwx   1 root     root           45 Sep 11 17:50 /lib/modules/2.6.18.2-34-default/build -> /usr/src/linux-2.6.18.2-34-obj/x86_64/default

Yup, but these (usually) don't change at run-time. So I would put them
into
the .rpm like any other sym-link (or delete and create them in the
pre-rm and
post-install scripts if it's not fixed at rpm-build-time).

> > just put the correct ones in /lib/modules/$(uname -r)/ and the full name
> > in
> > /boot/grub/menu.lst.
> 
> Which correct "ones"?  Sometimes pronouns aren't shortcuts :)

Sorry, the correct sym-links. Since I have no experience with recent
SuSE,
I didn't know that's the same as in the RedHat world (but they point
somewhere else).

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/