RFC: kernel-modules in Fedora Extras

[Thorsten Leemhuis]

Am Sonntag, den 15.01.2006, 00:00 +0200 schrieb Ville Skyttä:
> On Fri, 2006-01-13 at 16:27 +0100, Thorsten Leemhuis wrote:
> > Am Freitag, den 13.01.2006, 08:59 +0200 schrieb Ville Skyttä:
> > > The other part that shuffles stuff around %prep/%build/%install can
> > > result in specfile simplifications, 
> > 
> > Agreed. And there is an additional benefit: the debug-packages are a lot
> > smaller if you build more then one 
> 
> Hm, something missing from that sentence, 

Sorry, seems I got distracted at that point. 

> eg. "variant in the same dir"?

Yes, that would probably fit in well ;-)

> Actually, if I understand correctly, that's not a benefit, it's
> breakage.  The debuginfo packages would then contain the symbols and
> sources primarily for the last variant built in the loop plus possible
> leftovers from earlier builds, with probably most of the earlier builds'
> stuff overwritten or removed.

/me thinks about this for a moment -- Yeah, seems you are correct. 

> Both the contents of the sources and symbols may and do differ between
> variants, and it's possible for some variants to contain modules and
> sources not at all present for others (which should be obviously
> avoided).  The lirc package is an example of all this.

I should have thought of that. 

/me hides

> > If no one complains loudly soon about this fedora-kmodhelper idea in
> > above srpm then I think I'll work on modifying the last
> > extras-kmod-proposal to a solution with the fedora-kmodhelper scheme. 
> 
> +1

There is still one thing in my mind and I'd like to get other opinions
on it:

Should we have add a %{?kmod_per_package_add-on} into the output that
get_rpmtemplate creates? *If* a spec file needs something special in
each kmod package it could add a

%define kmod_per_package_add-on put stupid things here \
 probably even with newlines in them

in the spec file and get that part included in each kmod-Package.

Take for example the nvidia-drivers of a well known 3rd party repo: they
currently have a
Conflicts:  kernel-module-nvidia-legacy-%{kernel}
in them -- that would not be possible with the new scheme and that
sounds like a problem to me.

They also have some special things for %pre and %post which lead to the
question: Do we also need something like 
%{?kmod_per_package_add-on_pre}
%{?kmod_per_package_add-on_postun}

The whole kmodtools function would look like this (original stuff
quoted):

> get_rpmtemplate ()
> {
>     if [[ "${1}" = "up" ]] || [[ "${1}" = "UP" ]] ; then
>       local variant=""
>     elif [[ "${1}" ]] ; then
>      local variant="${1}"
>      local dashvariant="-${1}"
>     fi
> 
>     cat <<EOF
> %package       -n kmod-${kmod_name}${dashvariant}
> Summary:          ${kmod_name} kernel module(s)
> Group:            System Environment/Kernel
> Provides:         kernel-module = ${verrel}${variant}
> Provides:         kmod-${kmod_name} = %{version}-%{release}
> Requires:         kernel-%{_target_cpu} = ${verrel}${variant}
> Requires:         ${kmod_name}-kmod-common = %{version}
> Requires(post):   /sbin/depmod
> Requires(postun): /sbin/depmod
> BuildRequires:    kernel-devel-%{_target_cpu} = ${verrel}${variant}
%{?kmod_per_package_add-on}
> %description   -n kmod-${kmod_name}${dashvariant}
> This package provides the ${kmod_name} kernel modules built for the Linux
> kernel ${verrel}${variant} for the %{_target_cpu} family of processors.
> %post          -n kmod-${kmod_name}${dashvariant}
> /sbin/depmod -aeF /boot/System.map-${verrel}${variant} ${verrel}${variant} > /dev/null || :
%{?kmod_per_package_add-on_post}
> %postun        -n kmod-${kmod_name}${dashvariant}
> /sbin/depmod -aF /boot/System.map-${verrel}${variant} ${verrel}${variant} &> /dev/null || :
%{?kmod_per_package_add-on_postun}
> %files         -n kmod-${kmod_name}${dashvariant}
> %defattr(644,root,root,755)
> /lib/modules/${verrel}${variant}/extra/${kmod_name}/
> 
> EOF
> }

Back to the original mail:

> Here's a couple of updated example packages, converted to use kmodhelper
> (I suggest /usr/lib/rpm/redhat/kmodtool and %{kmodtool} for it, BTW)

Yeah, sounds good.

> and
> avoiding debuginfo problems.  Also added some additional known variants
> to the script.  The code in both packages is in a pretty bad shape
> regarding the latest Rawhide kernels (most modules disabled in lirc,
> thinkpad doesn't compile at all), but better on FC4, and anyway good
> enough for illustration purposes.
> 
> http://cachalot.mine.nu/5/SRPMS/lirc-kmod-0.8.0-0.8.pre4.2.6.15_1.1853_FC5.src.rpm
> http://cachalot.mine.nu/5/SRPMS/thinkpad-kmod-5.8-7.2.6.14_1.1656_FC4.src.rpm

Creat, thanks! Looks quite good.

CU
thl

-- 
Thorsten Leemhuis <fedora at leemhuis.info>