On Tue, Feb 14, 2017 at 7:53 AM, Stanislav Kozina <skozina@xxxxxxxxxx> wrote: > Hi Neal, > >>> 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? > > > Why that would need to be in a single package? You can always create two > packages that depend on each other. Or enhance ddiskit to cover your use > case;-) > I mean they are built from a single source package. The kmod and the utils would obviously be separate packages. :) >> 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. > > > The first version of ddiskit dates at least to 2007, at least 10 years back: > http://people.redhat.com/linville/ddiskit/ > >> In addition, while you consider it to be valueless to offer kmod >> packages, I would argue otherwise. > > > I didn't say that. > >> 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. > > > I think that this is the source of our disconnection. That's a very > different use case we're targeting. > The kmodtool, and, most importantly, the weak-modules script is targeting > packaging of kmods without recompilation with each kernel release. That's > what doesn't make much sense on Fedora. > We could just disable weak-modules in Fedora. In fact, why haven't we? It is useful for CentOS/RHEL, though. >> 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. > > > For the module recompilation case it seems that DKMS is the preferred > solution, as Panu also said. Why does RPM Fusion don't use that? > Where did Panu say that? I didn't see a message from him in this thread... >> 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. > > > I don't think that these two different cases should be mixed together. > Are the use-cases really different though? What makes backport kmod packages so different from regular ones? -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
