On 01/19/2012 02:01 PM, Pat Riehecky wrote:
> 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 think this "subsequent build" is where SL picks up some differences 
with the TUV as he does not build the whole distribution in the same 
environment.  While he builds from the published sources, to the best of 
my information he does not necessarily use mock or koji.  This was one 
area that CENTOS persisted in trying to make their distribution bug 
compatible with TUV as well as use the TUV sources.  This ideology was 
just one of several that led me to use SL.  Personally, I prefer a 
distribution where the tools used to build it are also part of the 
distribution.  I would hope SL could keep updated their documentation on 
their build environment as it changes.  I know their are times I have to 
spin off a package in order to complete a task.  I would like to use the 
same environment as that required to build the system.
> I hope that is clear,
> Pat
>
Thanks
Dr. Bahr