On 10/09/2007, Matt Domsch Matt_Domsch@dell.com wrote:
On Sun, Sep 09, 2007 at 05:51:28PM -0400, Michel Salim wrote:
On 09/09/2007, Jonathan Underwood jonathan.underwood@gmail.com wrote:
I thought that dkms had the ability to build an rpm and then install that. That would be the ideal solution.
Matt Domsch, who is (AFAIK) in charge of DKMS development, did not mention that at all.
There are several problems DKMS is designed to solve, and while clearly biased, I think it does so quite well. Dell honestly would not have been able to ship a product like RHEL, SLES, or Ubuntu without having a tool like DKMS available - which is why we wrote and continue to maintain it. We rarely change our factory images from the "gold" kernels of those products - the complete retesting required to do so makes it time-consuming and therefore expensive. We use DKMS to change individual kernel modules, with clear targeted changes that are easy to verify by code inspection and through runtime testing. We do this in cooperation with the developers at the distros, so the changes that are backported into a DKMS packaged module are then included in future distro updated kernels, which then eliminate the need for the DKMS packaged module.
Gary added 'mkrpm', at the request of people within Red Hat, several years ago. One can argue that the RPM spec file template that has evolved over time could be done differently or better, and you'd have no argument from me. The kmod work from SLES and RHEL, while each are different spec templates, both try to solve the same problem - make DKMS produce a source RPM containing source code, which is built in a build system to produce binary RPMs.
There are other spec file proposals, like Jef and others propose. Great! I haven't looked at all of them in detail, but with the 'mkrpm' and 'mkkmp' commands in DKMS, any of those spec file proposals should be usable by DKMS.
I would want any proposal made to include shipping the source code in the RPM, such that DKMS can rebuild modules on the fly (provided gcc etc. are available). I find this one of the "killer features" of DKMS
- it lets modules which are not presently "in the tree" get rebuilt
whenever "the tree" gets updated. It isn't perfect, but it's a whole lot better than having no such solution. With the module versioning code I helped get into the kernel, DKMS recognizes when a module is now "in the tree", and of same or equal version to what is provided by a DKMSified package. DKMS then defers to the in-kernel module rather than updating from its own - exactly the behavior we want to encourage (get your code into upstream and therefore into the distros; use DKMS as a backport mechansim for specific fixes older kernels, or in rarer cases, for currently out-of-tree modules which are working to get into the tree).
Ah, ok, I slightly misunderstood the use of mkrpm - I was under the impression that DKMS could build an rpm of the kernel module on the users machine (not in a repository buildsystem) and then install that. I.e. dkms, when it sees a new kernel on the users machine compiles the kernel module and packages at as an rpm and then installs it. Would that be implementable?