Once again: kernel-modules in the buildsystem

[seth vidal]

On Wed, 2005-09-28 at 16:50 -0400, Dan Williams wrote:
> On Wed, 2005-09-28 at 15:20 +0200, Thorsten Leemhuis wrote:
> > Dan, if something like that goes into mock -- what would be the best way
> > to make this new mock-option usable in plague for kernel-modules in
> > fedora-extras? Should plague automatically build the modules for all
> > kernels available (the one that was shipped and those currently in
> > updates-released)? Or only for the newest kernel available? Or should
> > the packager say something like "make plague KERNEL=put-kernel-ver-here"
> > when requesting build of a fdr-extras-kernel-module-pkg?
> 
> I recognize the need for this, there are a few questions that need
> answering here though.  First, methods.
> 
> 1) have plague automatically build for all kernels
> 
> Requires a large amount of work with yum to essentially list all
> kernel-* packages in a given repository, then queue up builds for them.
> That's a chunk of work.
> 
> 2) have plague build for latest kernel
> 
> Still requires work to ask yum about a certain repository to get latest
> kernel package.  Slightly easier, but not very much so.  Given that we
> are not guaranteed that the kernel-* package will be in the server's
> repository (it might be in the upstream "official" mirror instead) we
> pretty much have to use yum.
> 
> 3) have the packager do it
> 
> Pretty much the status quo right now, not much of a win IMHO.
> 
> 
> In any case, you're going to have to get some form of argument passing
> through Seth and into mock.  I don't like the "allow packager to pass
> random args" thing, since that's a direct impact on the security of the
> build system.  In the short term though, limiting such things to
> automatic rebuilds of kernel modules seems sane.
> 
> Ideally, yes, plague should be doing some depsolving on the server side.
> That's going to take a while to build in.  In the mean time, we could
> build in some kernel-module specific stuff, I'm not against that.  Most
> likely post 0.4.x work (1).
> 
> Some nice things that could go along with depsolving in the server:
> 
> - Store mock configs on the server and push them out to builders
> on-demand.  Bonus: we use same yum configs on server & builders.
> 
> - Don't build packages until their deps are satisfied, waiting a max of
> 8 or 10 hours before failing the package.
> 
> Dan
> 
> (1) That doesn't mean "a year from now" and work could start on that
> fairly soon after 0.4.x comes out, which is "in a few weeks"

sorry for being away for so long.

1. passing in kernel args is fine - but we're going to need to add a way
to vet them out to make sure someone doesn't play silly buggers with the
command line args passed to rpmbuild (ex: rpmbuild --define
'kernelver=something'; rm -rf /) as a dumb example. That's an obviously
malicious example but I'm more concerned about the just silly mistakes
that could hose up the buildsystem.

2. I don't like the idea of arbitrary defines being passed in for the
buildsystem - it makes for hard-to-replicate builds, I think. I know a
number of folks agree with me about that, too. With regard to the
kernels I think we could reasonably write a couple of simple yum-utils
that plague could use to query the chroot to find out what kernel to
build for. It wouldn't need to run as root once the chroot was setup b/c
the metadata would all be there.

So maybe this is a middle point but:

mock --defines=/path/to/some/file --other-mock-options-here

so then plague could just provide a defines file and mock would read
those in and add them to the rpm defines in the .rpmmacros in the
chrootbuilders homedir.

Or does that sound silly?

-sv