Am Dienstag, den 17.01.2006, 22:05 +0200 schrieb Ville Skyttä:
> On Mon, 2006-01-16 at 19:15 +0100, Thorsten Leemhuis wrote:
>
> > Should we have add a %{?kmod_per_package_add-on} into the output that
> > get_rpmtemplate creates?
>
> Urk, yes, I've considered stuff like that too, but hated it enough to
> not even suggest it ;)
>
> I hope and believe these things can be taken care of in the userspace
> $foo-common package, possibly using triggers if absolutely needed and if
> nothing else works.
Okay -- if we have to we can still revisit this decision if we have
to...
> > 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.
>
> Isn't it enough to make the userspace packages (ones providing
> nvidia-glx-common and nvidia-glx-legacy-common) conflict with each
> other?
/me thinks a moment about it
Yeah, *should* be...
[...]
> > > [URLs to sample packages]
> >
> > Creat, thanks! Looks quite good.
>
> Ok, next round: added RHEL4 compatibility (packaging-wise, not code).
> Informational patches to kmodtool and lirc-kmod.spec attached,
> containing only the essential changes that were made to accomplish this.
>
> http://cachalot.mine.nu/5/SRPMS/lirc-kmod-0.8.0-0.9.pre4.2.6.15_1.1858_FC5.src.rpm
> http://cachalot.mine.nu/5/SRPMS/thinkpad-kmod-5.8-8.2.6.14_1.1656_FC4.src.rpm
Looks quite good. One thing from your diff:
> - [ -n "${kvariant}" ] || kvariant=up
> - ksrc=%{_usrsrc}/kernels/%{kverrel}${kvariant#up}-%{_target_cpu}
> + if [ -n "${kvariant#up}" ] ; then
> + ksrc=%{_usrsrc}/kernels/%{kverrel}-$kvariant-%{_target_cpu}
> + else
> + kvariant=up
> + ksrc=%{_usrsrc}/kernels/%{kverrel}-%{_target_cpu}
> + fi
/me really would like to avoid constructs like
if [ -n "${kvariant#up}" ] ; then
....
else
....
fi
It looks really a lot nicer without them IMHO.
And, btw, do we really want to support both "up" and "" to build modules
for the standard kernel (which, btw, in the case of x86-64 is in fact a
smp kernel....)? We maybe should concentrate on one -- but "" looks a
bit problematic and is sometimes a bit harder to handle (for users and
people rebuilding the stuff)...
CU
thl
--
Thorsten Leemhuis <fedora@xxxxxxxxxxxxx>
--
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list
