On 01/19/2012 04:38 PM, Hubert Bahr wrote:
> 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.

It's noteworthy that I spent several months recently trying to more or 
less recreate the SL6 build in a completely automated way for 
Ascendos(.org) after Troy Dawson got the ball rolling on that project. 
At the moment I've sort of thrown up my hands for awhile, as there 
didn't seem to be sufficient interest in my particular brand of solution 
and/or leadership.

But the work remains at github.com/Ascendos if anyone is interested in 
the various stabs I came up with via inspection of available 
documentation and discussions.

A good essential question that my investigation, combined with the above 
description, yields is this-

Was ScientificLinux's 6.2 gcc built first against the 6.1 or 6.0 (or 
updates of either of those) gcc?  Note, I get the point about your 
dogfooding step of rebuilding against the first pass 6.2 output.  But 
what compiler was used to generate that first pass output?  The 4.4.4 of 
6.0 or the 4.4.5 of 6.1?  (or??)

And in general, is ScientificLinux capable of describing a deterministic 
algorithm used to make those choices, such that the answer can be 
gleamed from such, instead of residing only nebulously in the heads of 
various manual builders?

I tried to encode a first guesstimate of such a deterministic algorithm 
in my el-build script.  But I did run into very obscure problems during 
the generation of 6.1 installer iso output.  For now I've got enough 
months of other work I can tend to, hoping that by later this year 
others have pushed the issue towards documented/automated completion.

Anyway, for people interested in the landscape of this issue, this 
recent lwn article (and my arguably inflammatory attached comments) has 
some perspective on the issue.

http://lwn.net/Articles/473349/

-dmc



  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