On 01/19/2012 01:46 PM, Michael Tiernan wrote:
> On 1/19/12 2:38 PM, chinamusic wrote:
>> Building rpms from the srpms is easy and well documented.
>
> Thanks but he wants to build "our" SL RPMs.
>
> After some more back-and-forth with him, I understand the question 
> better: (Not that I like it much better.)
>
> If someone wanted to rebuild an existing RPM (the one that was used in 
> the example was "perl") *exactly* the same way it is done for the 
> current SL release process, how would it be done?
>
> The objective being, *if* they needed to, how could they reproduce an 
> existing RPM release using the SRPMS including all the same 
> configuration arguments?
>
> I'll phrase it this way, if someone wanted to set up their own 
> building environment for SL, where's it documented?
>
> I'm sure I've seen it before but I can't find it.

I can't find any published docs on our build environment right now, but 
the short version of it is, for SL6, we use Koji 
(https://fedorahosted.org/koji/).  It gives us a nice repeatable build 
environment in a clean mock buildroot with nice logs.  As for the exact 
reproduction, our koji instance points to the public SL trees for its 
repodata.  Packages are typically built with whatever TUV considers 
'current' at the time of release.  For example, when TUV released 6.2, 
we took the new source and built them, then we rebuilt them again using 
the new rpms for the environment - thus the new glibc published with 6.2 
was built by the new version of gcc (per 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48597) and the new gcc was 
built with the new glibc.  This 'first wave' of building is typically 
not published as the subsequent builds supersede them.

I hope that is clear,
Pat

-- 
Pat Riehecky
Scientific Linux Developer