On 10/09/2007, Matt Domsch <Matt_Domsch@xxxxxxxx> wrote: > On Sun, Sep 09, 2007 at 05:51:28PM -0400, Michel Salim wrote: > > On 09/09/2007, Jonathan Underwood <jonathan.underwood@xxxxxxxxx> 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? -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
