Adam Williamson wrote:
Yeah. I don't want to get too far into an issue I'm not
advocating for
in the first place, but, briefly: MDV builds DKMS 'binary' packages -
packages with pre-built modules, in a layout that DKMS understands -
(it's done semi-automatically from the DKMS 'source' packages) for the
most important modules (like NVIDIA and ATI) for the initial release
kernel and all official update kernels, for stable releases. These get
sent out at the same time as the official updates. So you can run the
most common external modules on an official release without DKMS ever
actually having to build the module.
(This is where a lot of the problems I alluded to came from. It took a
few years of experience to get this whole system to the point where it
actually *works* smoothly).
This isn't done for more obscure DKMS-handled modules, for backport and
third-party kernels, or for Cooker (Rawhide equivalent). If you use any
of those, you have to have the DKMS 'source' package installed, which
brings in the basic compilation toolchain and the appropriate kernel
headers via dependencies.
This is similar to how RPM Fusion's kmod (binary packages) and akmod
("source" packages similar to the DKMS ones) setup works.
I've probably read several alternative incarnations of much the
same
discussion. =) It is somewhat inherently a painful area, and MDV
certainly has quite a lot of tweaking to DKMS and some significant
internal architecture to make it all work more or less smoothly.
They must have done so, because RPM Fusion decided DKMS is not suitable for
binary packages and thus developed their own solution (akmod) which uses
the same specfiles for the akmod packages and the binary kmod packages.
Which is why I said it's probably not worth the effort.
But can't we just reuse the work from RPM Fusion or from Mandriva?
Kevin Kofler