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