[OpenAFS] In the RPM spec file, what is the goal of the special fedora option?

Simon Wilkinson sxw@inf.ed.ac.uk
Wed, 13 Feb 2008 19:00:35 +0000

On 13 Feb 2008, at 17:47, Derek Atkins wrote:
> I'm afraid I don't understand what you mean that it wasn't possible
> to build for multiple kernels using the old-style kernel module
> packaging?  Before the automated system I was most certainly building
> for a multitude of kernels.  Granted, I don't think the number was
> up to 700, but it was certainly over 100.  The build scripts were
> quite easy and it used the single RPM/SRPM (plus an external script)
> to perform the multiple builds.

Perhaps 'possible' was the wrong choice of words. The dependency  
generation in the old system meant that you couldn't build using  
mock, as mock wouldn't correctly populate the chroot. It's mock that  
lets us build across all supported distributions without needing  
multiple VMs, and avoids the problems that RPM runs into when you try  
to have 100 or so kernel-devel packages all installed at the same  
time. Whilst it was possible to script mass rebuilds with the old- 
style kernel module format, this generally lead to having to have a  
build machine (or VM) per operating system, and to manually juggling  
the set of installed kernel-devel RPMs that were being built against.

It would have been possible to add the build-time dependencies that  
are required for mock to work to the old style packaging. In effect  
that's what we've done by using kmodtool - but we've also taken the  
opportunity to tighten up the dependency relationships, so things  
work better with yum, and to move to the more standard naming scheme.  
None of this has changed the userland packaging, which still all  
comes from the original OpenAFS SRPM.