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@xxxxxxxxxxxxx>
--
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list
