[ATrpms-devel] Re: DKMS

Sat May 22 10:54:44 CEST 2004

Hi, Axel!  Quick reply!  Sorry, I haven't been following this list very
carefully; I thought I was paying attention to the DKMS stuff (which was
just recently moved on-list, no?).  The kernel-module-foo thread set my
head spinning.

It's spinning again!  Can you describe in detail exactly how you think
this will work?  In step C, you end up with a kernel-module-foo RPM. 
What is in that RPM's specfile?  Does it invoke DKMS commands to build
and install the module (into DESTDIR) in step B?  And these binaries are
then put in the binary RPM?

In this case, we still need a separate specfile for each possible
kernel-version/module-version pair, because the versions numbers that
are fed to the DKMS commands still need to be changed within the
specfile.  We still need a configured kernel source tree for the
particular desired kernel flavor.  And the main difference between the
whitepaper's RPM method and this one is that you're running the DKMS
build and install commands during the %build script rather than during
the %post script (which IS way better, but which still requires an
end-user to have DKMS installed and configured on his build machine to
rebuild the kernel module SRPM).  It seems no less transparent than just
building a normal SRPM against an installed kernel-source RPM, which
every kernel RPM builds one of (see my system below), and just adds
extra complication to the system (need DKMS installed/configured) and to
the build process (adds an extra level by removing build scripts to the
dkms.conf file).

As far as being universal and applying to non-RPM-based distros, is that
one of the problems you're trying to solve?  I'm for that, too, but I
can't see how the below solution tackles that, since it is a method to
encapsulate the DKMS module-building process in an RPM.  In order to get
DKMS popularized upstream, we'll need a heavyweight like RedHat to get
in on that game first for people to start following.

***

Here's how I'm doing it, which makes a lot of sense to me, and which
deals with many of the problems I've heard here, and which fits pretty
neatly into existing systems that AFAIK all RPM-based distros have.

1. We begin with a RedHat kernel RPM and a module source tarball.

2. We may optionally modify the kernel RPM in probably minor ways; maybe
we add a patch or something.  The kernel RPM has a special macro
'targetboard' that can be specified to build a kernel with a special
.config file, eg. kernel-2.4.18-i[36]86-host108.config.  This should
address your concern about kernel 'flavors,' unless you mean something
else entirely:  If '--define "targetboard host108"' is specified on the
rpmbuild commandline, instead of the normal 'kernel-2.4.18-14.i686.rpm'
and 'kernel-smp...' rpms, we get a 'kernel-2.4.18-14host108.i686.rpm',
and specifying '--target i386' builds a
'kernel-source-2.4.18-14host108.i386.rpm' that installs into
/usr/src/linux-2.4.18-14host108/.

3. Install the kernel-source RPM to create the
/usr/src/linux-2.4.18-14host108/ directory.

4. Next, we write a specfile (check out my ivtv SRPM as a reference). 
At the top of the specfile, we do a '%define kernelversion 2.4.18' and
'%define kernelrpmrelease 14'.  Of course, for a new version of a
module, we have to change the 'Version:' line, too.  Doing an rpmbuild
on this specfile unpacks and builds the module source, and points it
towards the installed kernel-source RPM in /usr/src/linux-2.4.18-14/. 
By default it builds
kernel-module-<mymodule>-<version>-<release>.i686.rpm and
kernel-module-<mymodule>-smp... binary RPMs which are installed
alongside the corresponding kernel-[smp-]2.4.18-14.i686.rpm.  In the
case of a special kernel 'flavor,' we run 'rpmbuild --define
"targetboard host108"' just like we do with the kernel RPM, which then
builds kernel-module-<mymodule>-<version>-<release>host108.i686.rpm.

5. That's it!  

If I understand your 'flavor' problem correctly, it solves the problem
of having many kernel versions and flavors that we want to build modules
for.  It automatically builds normal (uniprocessor, "") and smp binary
RPMs for ordinary kernels, or special binary RPMs for the special flavor
(host108).

It is generally rebuildable by any user, who can rpmbuild --rebuild on
the SRPM on his own system, and if the normal RedHat build environment
and the kernel-source rpm is there, it will work.

There is no need to provide a special framework for end users to package
special kernel flavors, since RedHat has already done that for them with
the 'targetboard' mechanism, and has already defined the RPM naming
scheme for such kernels (ie. adding the targetboard's name to the
release).

DKMS is, of course, absent from this scheme.  There is no need for the
user to install it and correctly configure it.  RPM already has its
analogs for the DKMS 'build,' 'install,' 'uninstall,' and 'status'
commands; there's no need to bring in this functionality from somewhere
else.  DKMS seems better-suited to those who don't care about rolling
module RPMs, and it seems that its RPM support was conceived as an
afterthought (despite the whitepaper's claims to the contrary).

Finally, this system is tested and works; see my SRPM (this is a ROUGH
draft, ugly, needs work):

	http://bigu.org/SRPMS/ivtv-0.1.10-1bigu.src.rpm

In fact, I'm not terribly concerned which way ATrpms goes; I'm just
bootstrapping a few of my own RPMs off of yours (thank you!! ;).  If the
ATrpms kernel module RPMs can't be rebuilt for arbitrary kernel RPMs, I
will have no way to use them, and will continue to use my own system. 
On the other hand, if ATrpms figures out these issues and makes it easy
to rebuild and install kernel module RPMs on my systems simply and
without needing to add a huge amount of baggage, I'll convert instantly
(and even start contributing).  My guess is that there might be a few
others out there who are in this boat; I've seen several posts by folks
who try that first time to run an rpmbuild and run into the missing
macros problem, so we know there are others out there who would like to
rebuild the module packages.

That's all!  Sorry if this sounds like a rant, it's really not.  I hope
I explained in detail a possible, practical, working solution to the
problems I've heard here, and that they'll be useful in some way.  :)

	John

> John, you do have valid points, but there are merrits a system like
> DKMS has: If it gets widely used enough upstream tarballs could
> contain configuration files for DKMS, and also DKMS is not bound to
> rpm, neither a particular distribution - it could be used by deb-based
> distros as well, or any other packaging system, including no packaging
> at all (a la LFS). I very much like the universality of this approach.
> 
> The scheme I proposed to Gary (perhaps even on this list?) is the
> following:
> 
> A) You have packaged sources like the usual src.rpms.
> B) These produce drop-in module sources prepared for a DKMS framework
> C) These again produce the kernel module rpms as we currently know
>    them.
> 
> The middle step is what currently ATrpms does in its own way by
> unpacking and preparing kernel sources. As it requires an environment
> as set up at the ATrpms build machines it makes life hard for end
> users to repackage the kernel modules.
> 
> DKMS is a good candidate to substitute this middle step in a
> transparent way, which could be used by users, too. There is still
> some work to be done (DKMS does not yet support installing into an
> alternative DESTDIR, which is needed for step C) above), and of course
> the issues you mentioned about mixed builds, e.g. producing both
> kernel modules and userland stuff (but perhaps there is a solution in
> DKMS already).
> 
> Personally I want to have something to allow end users to be able to
> rebuild kernel modules for their custom kernels (Vendor kernels are
> less interesting, there are already kernel modules available for
> that. Users/developers are interested in doing it for their own
> kernels). Of course in a framework where we want the end product (the
> kernel modules) to appear as an rpm, we also need to make sure the
> user has his custom kernel in form of an rpm.
> 
> So the first step will be to provide a framework for end users to
> package their kernel flavour into a kernel-<myflavour>-...rpm. Then
> any kernel module solution will pick the flavour ("", "smp",
> "host108") and build kernel modules against this configuration.
> 
> I hope I'll get some time to look into DKMS, I have currently only
> read the paper on it and have packaged and placed it into ATrpms. When
> the dust around FC2 settles I hope I'll find some more time. :(
> -- 
> Axel.Thimm at ATrpms.net
> ----
> 

> _______________________________________________
> atrpms-devel mailing list
> atrpms-devel at atrpms.net
> http://lists.atrpms.net/mailman/listinfo/atrpms-devel