2:10 p.m.
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