RFC: kernel-modules in Fedora Extras

[David Woodhouse]

On Fri, 2006-01-06 at 13:43 +0200, Ville Skyttä wrote:
> On Fri, 2006-01-06 at 11:09 +0000, David Woodhouse wrote:
> > On Fri, 2006-01-06 at 11:30 +0100, Thorsten Leemhuis wrote:
> >
> > > %if 0%{?variant:1}
> > >     kmod_build %{variant}
> > > %else
> > >     %{?kmod_build_up:  kmod_build up}
> > >     %{?kmod_build_smp: kmod_build smp}
> > >     %{?kmod_build_xen-guest:kmod_build xen-guest}
> > >     %{?kmod_build_xen-hypervisor:kmod_build xen-hypervisor}
> > > %endif
> > 
> > What if you want to build for, for example, up, smp and hugemem kernels?
> > Do you have to build the same RPM twice?
> 
> Actually, if you want to build _exactly_ for those three, you'd need to
> rebuild it three times (once for each like --define 'variant foo'), or
> modify the specfile, removing xen-* and adding hugemem.

I thought I could do one pass to build for both up and smp, then another
to build the hugemem variant?

> >  I'd like to see the handling of
> > available variants get a little more cunning. The packager shouldn't
> > need to know which variants are available
> 
> Very much agreed (and ditto for archs!), but no good solution has been
> found so far, and IMNSHO this is not something that should block
> starting shipping modules in Extras.  It's an implementation detail
> which can be improved later if someone comes up with a good solution.
>
> > Couldn't we make the variant list available somehow? Each kernel-devel
> > package could include a text file telling the variants which are
> > available for that architecture in that build, perhaps?
> 
> I'm not sure how such a text file could be used.  Lack of looping
> constructs in specfiles doesn't help :(

Oh, you can do looping constructs in specfiles. It's just not _pretty_.
I did it once, addressing precisely this problem. I can't remember how,
but I think I'm happier that way. 

What chance of extending rpm with a '%foreach'?

Another thing which would be nice to have is a buildsystem-trigger which
automatically rebuilds the kmod package(s) when a new kernel becomes
available. And do we actually have machines building ppc64 for Extras
yet? You don't need actual ppc64 hardware -- the ppc32 compiler is
perfectly capable of generating ppc64 output (for kernel modules and
anything else that isn't autocrap-damaged, at least).

-- 
dwmw2