Once again: kernel-modules in the buildsystem

[Dan Williams]

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"