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.
Thanks, Niels
On October 7, 2018 12:37:37 PM GMT+03:00, Niels de Vos ndevos@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
On 07/10/18 10:58, Manuel Wolfshant wrote:
On October 7, 2018 12:37:37 PM GMT+03:00, Niels de Vos ndevos@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
You have your answer, but I'll add to Wolfy's response above if I may.
The RHEL way of packaging kernel modules is to use kmods under the Driver Update Programme infrastructure which exists for exactly this purpose, taking advantage of the stable kABI that exists in RHEL kernels.
Please don't be tempted to follow or refer to the various concoctions of methods derived from Fedora which doesn't have a stable kABI and were devised to solve issues that simply don't exist in RHEL. Use the tools Red Hat provides in RHEL - kmods are the accepted way of packaging kernel modules in RHEL.
On Sun, Oct 07, 2018 at 03:06:39PM +0100, Trevor Hemsley wrote:
On 07/10/18 10:37, Niels de Vos wrote:
Hi,
There is an oustanding request for the Storage SIG to package and provide VDO:
Is there a problem with the copy that the distro already provides?
kmod-kvdo.x86_64 6.1.0.181-17.el7_5 updates vdo.x86_64 6.1.0.168-18 updates
Oh, wow, interesting! I guess the different people asking for it were also not aware it is included in the base.
Thanks for pointing it out, this saves me some work :D Niels
On 07/10/18 16:04, Niels de Vos wrote:
On Sun, Oct 07, 2018 at 03:06:39PM +0100, Trevor Hemsley wrote:
On 07/10/18 10:37, Niels de Vos wrote:
Hi,
There is an oustanding request for the Storage SIG to package and provide VDO:
Is there a problem with the copy that the distro already provides?
kmod-kvdo.x86_64 6.1.0.181-17.el7_5 updates vdo.x86_64 6.1.0.168-18 updates
Oh, wow, interesting! I guess the different people asking for it were also not aware it is included in the base.
I think it was a 7.4 addition.
Trevor
-
Manuel Wolfshant -
Niels de Vos -
Phil Perry -
Trevor Hemsley