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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
