kernel modules in RPM Fusion; we need a decision

[Thorsten Leemhuis]

On 01.09.2008 22:13, Denis Leroy wrote:
> Thorsten Leemhuis wrote:
>> My (obvious) vote and option: kmods and akmods afaics provides all we 
>> and the users need. We could get dkms into the mix but that would just 
>> provide a similar functionally as akmods with the disadvantage that a 
>> second spec file/compile path would need to be maintained and tested -- 
>> that would mean a whole lot more work with afaics no real benefit.
> How do akmods work?

In the end the akmods executables are a few small or medium sized shell 
scripts that rebuild a kmod.src.rpm (which is found in the akmod-foo.rpm 
package) and install the resulting kmod. It does that if the modules in 
question for the running kernel is not found during bootup (or on 
kernel-install, but that's a different use case and not that important 
here; dkms can do the same).

> Do you have to install both kmod and akmod?

No, but you can if you want to have a automatic fallback.

> Also, is akmod really a 0 maintainance solution like dkms?

Can't answer that without a exact definition of what "0 maintainance 
solution" means.

If you meant "You install a akmod; later you boot random Fedora or 
self-compiled kernels for which the -devel files are available in the 
usual places; will the kernel-module be automatically build and 
installed" then the answer is "yes" (of course their might be bugs in 
akmods, but it seems to work quite well and all software has bugs)

> Finally, dkms is particularly simple to package. 
> Is akmod documentation comparable to that of dkms ?

Akmod pacakges get build from a stock kmod. The docs for kmods are 
written like a reference doc to explain each and every detail -- that 
makes it not that easy for the start, but is helpful if you want to 
understand how things work together.

Staring from a kmod template or an existing kmod is liekly easier; most 
people that are used to rpm packaging should quickly understand the most 
important bits, as a kmod spec file is not that hard to understand. In 
fact, if you have two properly packaged upstream modules then the %pre, 
%build and %install section can be the same for both. They will look 
like this:

%prep
%setup -q -c -T -a 0
for kernel_version in %{?kernel_versions}; do
     cp -a %{tarball_name} _kmod_build_${kernel_version%%___*}
done


%build
for kernel_version in %{?kernel_versions}; do
      make V=1 -C "${kernel_version##*___}" 
SUBDIRS=${PWD}/_kmod_build_${kernel_version%%___*}
done


%install
rm -rf $RPM_BUILD_ROOT
for kernel_version in %{?kernel_versions}; do
      install -D -m 755 _kmod_build_${kernel_version%%___*}/gspca.ko 
$RPM_BUILD_ROOT%{kmodinstdir_prefix}/${kernel_version%%___*}/%{kmodinstdir_postfix}/gspca.ko
done
%{?akmod_install}

> To me, kmod can only be acceptable if AND ONLY IF the rebuild of the 
> kmod packages is automated based on a RSS feed coming from Koji or Bodhi 
> of some sort. i.e. guarantee a zero-time dependency break from kernel 
> updates.

Impossible -- we want to sign rpms manually (juest like Fedora does; 
they just showed why that is important). A lot of the other tasks for 
rebuilding kmods are scripted, but not fully automated yet -- I have a 
long todo list for RPM Fusion and other things seem to be way more 
important to me.

BTW, why do you care how quick kmod get released? You seem to be in 
favour of dkms. It's counterpart is akmod so feel free just use that -- 
the akmods won't be re-released when a new kernel shows up. And btw, 
livna was quite good in shipping new kmods just-in-time for new kernels. 
It was only a real problem recently when the buildsys was down for a few 
days.

Kmod on the other hand provide an addition benefit that we would not 
have with dkms: pre-compiled modules. That for example is important for 
small machines for example -- a few livna users with the first-gen Asus 
Eee PC for example were really glad that they got a pre-compiled 
madwifi-kmod in livna-testing. Most of those users didn't want dkms or 
akmods as they didn't want to install gcc and its deps on the samll SSD; 
the users afaics also did not want to wait for the module to compile 
(which takes quite a bit longer on small machines like the Eee PC).

Cu
knurd