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

[Derek Atkins]

Simon,

Simon Wilkinson <sxw@inf.ed.ac.uk> writes:

> 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.

Okay, that makes more sense.   One of these days I'd like to learn
more about the new OpenAFS auto-build system.  Are all the scripts
and such in CVS?

> 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.

Sounds reasonable.  It's sorta what I was TRYING to do before, but
obviously didn't get far enough.

> Cheers,
>
> Simon.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available