[ATrpms-devel] Re: dev question--compiling kernel-module-lirc rpm as normal user against a 'kernel-source' rpm

[Axel Thimm]

On Tue, May 25, 2004 at 05:23:48PM -0500, John Morris wrote:
> I think that you might've been too busy with the FC2 stuff,

Yes.

> and haven't really followed what I've been saying.

No, I have. ;)

> Let me spout it off again.  ;) I'll try to explain as clearly as
> possible.

> 1)  My systems run *custom* kernels that are based on the RedHat RPMs. 
> How do you customize a RedHat kernel RPM?  Two ways:
> 
> 	a)  By adding or removing patches from the kernel RPM:  Currently I
> remove most of RedHat's patches, and apply my own.
> 
> 	b)  By using a custom .config file:  the RedHat RPM provides a
> mechanism where you can define a macro called 'targetboard'; that will
> use a special .config file and create a special RPM for that particular
> kernel.
> 
> I've been trying to get you to answer this question:  Why do we need to
> invent a special system for users to package custom kernels into RPMs
> when RedHat has already given us a modifyable and customizable kernel
> SRPM?

a) is a complete overshoot for an end user to build a kernel rpm. It
requires knowledge about rpms, Red Hat's patching techniques, build
all flavours, when you only need one and so on. This is for producing
a set of kernels for wide distribution, not for users to customize
their machine.

b) targetboard? Not available in any Fedora Core kernel from Red
Hat. Perhaps an attempt to do so in prior kernels, which was dropped
later (or renamed). But still the kernel srpms, even if customizable
w/o editing specfiles are not intended/suitable for the end user's
kernel packaging.

So you are still missing a mechanism to allow _end users_ to produce
kernel rpms. Without which it is moot to have them produce dangling
kernel module rpms.

> 2)  When you build the kernel RPM, a kernel-source RPM is also built. 
> It is installed into /usr/src/linux-<kernelversion>-<rpmrelease>/ and
> contains *pre-configured* sources with symbol versions, etc.; it is all
> ready to build working modules against, right out of the box!  You can
> actually install several kernel-source RPMs simultaneously; here is a
> sample listing:
> 
> 	/usr/src/linux-2.4.20-8/	# stock RH9 kernel source
> 	/usr/src/linux-2.4.20-8host108/	# stock RH9 kernel rebuilt with
> 					# 'targetboard' set to 'host108'
> 	/usr/src/linux-2.4.18-14/	# stock RH8.0 kernel source
> 
> You *can* use any one of these kernel-source rpms directly.  You don't
> need to modify Makefiles, and don't need to reconfigure for the target
> kernel; they're already configured.

No, it is not. There are some Red Hat hacks to make it appear so for
the Red Hat distribution (up to FC1, but not FC2 anymore!), but as
soon as you try to change the config you need to provide the same set
of hacks customized for your kernel config. This solution does not
scale for custom kernels at all ... :(

Been there, done than, got hurt, stopped doing that ;)
(and Red Hat obviously, too)

> You can install as many kernel-source RPMs as you like; they don't
> conflict, and can be layed out nicely right next to each other in
> /usr/src.  To change a specfile from building a module for the RH9
> kernel to building one for the RH8 kernel, you only have to change
> the version number on one line in the specfile.  No PITA at all!
> 
> 3)  I haven't reinvented the wheel; I've taken two of your kernel-module
> RPMs, ivtv and lirc, and modified them so that they can build *as a
> normal user* against any of these installed kernel-source RPMs.  They
> produce proper kernel-modules with the right symbol versions that
> install in the right place.  In the case where you're building against a
> stock RedHat kernel, two kernel-module RPMs are built:  one for SMP, one
> for UP.  These RPMs *work*.  You can download the ivtv module right now
> and try it out.

The other ones work, too, and are already layed out for
flavour-agnostic setups. I am only missing a good kernel packaging
mechanism. Which is not hard to do, I had it working at RH7.3 times.

> Again, I'm just suggesting that you adopt this method too.  I don't
> have any idea what you're doing on your dev boxes, and you haven't
> explained, so I'm probably missing something important here.

I explained that you need expanded and configured/prepared kernel
sources for each flavour/arch combination. The rest is simply
following the kernel modules' documentation.

> But from the hints I've gathered, it sounds pretty hairy,

Ahem, there is nothing hairy about the way ATrpms does it, it is just
the _only_ way to do it. You rely on some Red Hat extra magic to
distinguish your kernel configs, which sometimes works and sometimes
not, and to the best of my knowledege was dropped in FC2 ...

> and your specfiles contain lots of strange-looking macros that must
> do some interesting acrobatics to work.

s/interesting acrobatics/neccessary steps/

I only wished there was a better kernel source deployment method in
packaged form, which would not require dedicated kernel source trees.

(Well in fact there is, you could have each kernel module rpm install
kernel-source perform a mrproper and conifg/prepare step and then
build, but that would require 10 times as much building time per
kernel, and for O(5000) kernel modules, this time is not available)

The "hairy" "acrobatics" macros are layed out in such a way that you
can do both, have a dedicated kernel build machine or have a full
kernel purge/configure/prepare preludium. Just fill the macros with
the implementation you prefer.

> My RPMs are very straightforward, easy to read, don't require any
> strange macros.  The only thing they require is the kernel-source
> RPM from a RedHat-style (either stock or customized) kernel RPM.
> 
> Get the ivtv SRPM here.  You'll see it's mostly your code in the
> specfile.  You really should give it a look!  
> 
>    http://bigu.org/SRPMS/ivtv-0.1.10-1bigu.src.rpm

Try building for FC2 kernel, or any vanilla set of kernels and you
will see where it will break.

I understand your excitement, but the problem is scaling and
universality. Having a solution valid for RH9 and FC1 which works with
80% of modules is already nice, but we are past this point already.

I believe in solutions like DKMS, which are layed out to scale well
even across distributions and independent of packaging tools. There is
some gluing neccessary to get the same benefits we have today with
kernel module rpms, but I believe that it is worth while.

Let's see, I first need to come up with a good kernel packaging scheme
for end users. Before that I need to open up developer accounts at
ATrpms. Before that I need to get FC2 support ironed out. Before that
I need some breakfast ;)

> Thanks!
> 
> 	John
> 
> 	
> 
> > you cannot use the kernel-source rpm directly, you need to modify
> > Makefiles and reconfigure for each target kernel. For kernel module
> > rpm "production" you need to have kernel sources layed out for each
> > flavour/arch combination. :(
> > 
> > That's the real PITA. :/
> > 
> > Anyway, why reinvent the wheel, when there are lirc kernel modules
> > rpms already at ATrpms? If you want to support custom kernels, one
> > should first support packaging these into rpms, otherwise you will be
> > producing dangling kernel module rpms (i.e. no dependencies, no
> > automated, reproducable builds in chroot etc.).
> > 
> > BTW all ATrpms rpms are built as a non-root user.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.atrpms.net/pipermail/atrpms-devel/attachments/20040526/08105d9c/attachment.bin