Hi, On 13-02-17 14:27, Stanislav Kozina 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.
That sounds like a fine plan.
The ddiskit v.3 should be used as a replacement, we plan to propose it as a Fedora base package soon
As explained by Neal Gompa 3th part repos have invested a lot of effort into kmodtool and that will likely stay the preferred way for them to package modules going forward at least for the short term. So I think it would be good to: 1) Drop the ancient kmodtool / entire kernel-module-macros package from redhat-rpm-config 2) Move kmodtool from rpmfusion to Fedora proper (where it can be shared with other 3th party repos) and extend it where necessary for other repo use-cases 3) Get ddiskit packaged into Fedora proper and promote people to use it for new kernel module packages / convert existing packages over (if the maintainer wishes) Think of this as how yum and dnf co-existed for a while. > 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. I'm mostly coordinating things here, I'm not an expert on kernel module packaging, so I'll let others weigh in if that is a good idea, specifically it would be good to know if existing kernel (module) packages depend on this ? Regards, Hans _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
