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;-)
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.
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?
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.
Thanks,
-Stanislav
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
