On Mon, Feb 13, 2017 at 11:50 AM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > 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 ? > I honestly do not think it will ever be feasible to use ddiskit for all kmods because it enforces kernel source structure and makes it infeasible to have userspace and kernel module tools packaged together. As a maintainer of an out-of-tree kernel module package[1] working on supporting akmod and kmod packages, I don't think there's ever going to be a chance that I'll use ddiskit because it's too inflexible. Now, if you want to support ddiskit style packages within kmodtool and the existing kmod stuff, that's fine and great. It looks like ddiskit would be great for making backport kernel module packages available, as it conforms to that structure. But it's otherwise impractical for most kmod packages to use. [1]: https://github.com/datto/dattobd -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
