On Mon, Feb 13, 2017 at 8:27 AM, Stanislav Kozina <skozina@xxxxxxxxxx> wrote: > Hello Hans, > > (adding some more folks on CC..) > > You've correctly mentioned one of the problems with the kmod tools, that > there are several versions in a various stages of loneliness. The other > problem is that the usage of them is not trivial, eg. the > %kernel_module_package macro (as the main user of the kmodtool) is quite > complicated and limiting in the options you might need for the kmod build. > > For this reason we have recently developed a new tool which can be used to > build a kmod. It doesn't use anything from the kernel-module-macros package, > instead, it helps you to create a correct directory structure, generate a > .spec file and package your kernel modules using this .spec file. This > should make the kmod build much more self-contained. The tool has been > recently also added to the Fedora COPR repository: > > https://copr.fedorainfracloud.org/coprs/ersin/ddiskit/ > > Because of the current status of the content of the kernel-module-macros > package I think it would be better to just remove it from Fedora completely. > The ddiskit v.3 should be used as a replacement, we plan to propose it as a > Fedora base package soon. The kernel module support from the > /usr/lib/rpm/redhat/find-provides script might also be removed, together > with the /usr/sbin/weak-modules script. > > It's worth mentioning that building kmods for Fedora won't make much sense > because Fedora doesn't have a stable kernel ABI. > So how do you handle when kmods and userspace tools are built as part of a single package? It seems like ddiskit is a rather myopic solution. Not to mention, kmodtool has a very large userbase and this is literally the first time I'm hearing of something like ddiskit. In addition, while you consider it to be valueless to offer kmod packages, I would argue otherwise. Just because our tooling doesn't allow us to track kernel releases and automatically build/rebuild kernel module packages to target new kernels, doesn't mean others don't (notably, building kmod packages with OBS tracking fedora updates repo works quite well, and akmod works brilliantly as an alternative path) and that others wouldn't find it useful anyway. RPM Fusion has been maintaining the kmod packaging standard since Fedora (imho, wrongfully) expelled the specification and stopped developing it. This is what ultimately led to the crazy fragmentation we have across Fedora, RHEL, RPM Fusion, and other groups. Instead, I propose that the ddiskit developers fold their work into kmodtool and the kmod packaging work that RPM Fusion has done, so that we have a unified solution. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
