On October 7, 2018 12:37:37 PM GMT+03:00, Niels de Vos <ndevos at redhat.com> wrote: >Hi, > >There is an oustanding request for the Storage SIG to package and >provide VDO: > >> VDO (which includes kvdo and vdo) is software that provides inline >> block-level deduplication, compression, and thin provisioning >> capabilities for primary storage. > >Both components ate packaged in a Fedora COPR, and a reasonable .spec >file is provided by the upstream project. > >However, the kernel module is packaged with DKMS. This would result in >building the module during RPM installation, and possibly on reboot >after a kernel update. > >There is a dkms package in the CBS (by Haïkel), but it is only tagged >with -candidate. I would like to know what the reasons were to not >consumer it for a release. > >It seems that there is one (that I could find) package in the CBS that >provides a kernel modules (openafs-kmod by Jonathan). It utilizes DKMS >as well, but also never made it a repository for release. > >Then there is the kmod package (build by Lokesh). This is an >alternative >way of building kernel modules. It compiles the module in the CBS, for >a >specific (sortof major) kernel version. The resulting RPM can then be >installed without the need to build it again. > >My personal preference would be to provide kernel modules with the kmod >practise. But I love to hear opinions and experiences from others. > dkms requires the presence of compiler and a ton of devel packages . I prefer to not have any of those on servers. So +1 for kmods Wolfy, former packager of ath and realtek modules in dkms format