[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Kernel modules in Fedora Extras

On Mon, 2006-05-15 at 19:45 +0200, Thorsten Leemhuis wrote:
> Am Montag, den 15.05.2006, 12:47 -0400 schrieb Dan Williams:
> > On Mon, 2006-05-15 at 18:15 +0200, Thorsten Leemhuis wrote:
> > > Am Montag, den 15.05.2006, 10:45 -0400 schrieb Dan Williams: 
> > > > On Sun, 2006-05-14 at 20:44 +0200, Thorsten Leemhuis wrote:
> > > > > Just FYI, I took the old kernel-module proposal and reworked the
> > > > > document a bit and put it in the proper place at:
> > > > > http://www.fedoraproject.org/wiki/Packaging/KernelModules
> > > > > Might sill be a bit rough and the standard and the page still needs some
> > > > > finetuning. But it's probably a lot better than before.
> > > > Is there anything needed from the buildsystem for this?  AFAIK you can
> > > > already to i686, i586, ppc, and x86_64 kernel modules.
> > > Well, in and ideal world plague, mock or something else would pass the 
> > > - version of the latest kernel to the rpmbuild-call via "--define
> > > kversion foo"
> > > - all variants (smp, "", xen0, xenU, ...) via "--define kvariants bar
> > > baz"
> > > when building the package. That would avoid the hardcoding of those vars
> > > in the spec file.
> > I think we can do that in a sane way, yes.
> Great :)
> Ohh, I forgot -- we currently use something like
> ExclusiveArch: i586, i686, x86_64, ppc
> to specify the target archs to build for. Some people don't like that --
> it would be good if the buildsys could handle this, too (but of course
> the buildsys should not try to build for i386 -- that will fail). 

Out of curiosity, what _do_ they want to do?  Do they just want to put
nothing in the specfile and have it work magically?

If we're talking a clear & simple approach, people have one option:
ExclusiveArch: i586 i686 ...

If we want to "assume" what the user wants, then we do all the magic in
the build system and it's completely unclear _outside_ the buildsystem
what architectures the kernel module actually builds on.  Assuming isn't
necessarily a bad thing, but if you take it too far stuff gets really
unclear and you start not doing things people expect.

The situation here would be that the package would build everywhere by
default, and if the user doesn't want a specific architecture, they have
to ExcludeArch that particular one.  So we're right back to having to
put that stuff back into the spec.

It's a tradeoff:  you either make expectations quite clear upfront, or
you run around answering questions about why the buildsys does what it
does because things are less clear.

I guess we can just extend the additional package arches stuff in the
buildsys config to do something like "!i386 !i486" and exclude those
arches automatically, but build on all the rest.  The problem is that
this config option is a "you can build these if you want to", not a
"these will be built unless you exclude them".  I can look into
expanding the syntax here to account for everything.

> I tried to build a kmod for ppc64 with mock once -- worked just fine
> after removing the 
> Exclude = *.ppc64
> from the mock-conf for the target and putting
> ppc64-redhat-linux
> into /etc/rpm/platform on the host. So it shouldn't be a big deal to set
> a plague-builder up for ppc64 somewhere. But how to we make sure that
> only kmod's are build for ppc64 (and not everything). Can plague handle
> that?

Yeah, I can look into this, though we've had issues with some stuff in
RPM recently (RH Bug #171391).


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]