<div dir="ltr">Is there a mock config that can be used by others yet?<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Dec 23, 2013 at 8:28 AM, Lamar Owen <span dir="ltr"><<a href="mailto:lowen@pari.edu" target="_blank">lowen@pari.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 12/22/2013 02:11 AM, Steven Crothers wrote:<br>
> On Thu, Dec 19, 2013 at 11:22 AM, Lamar Owen <<a href="mailto:lowen@pari.edu">lowen@pari.edu</a>> wrote:<br>
</div><div class="im">>> While on the surface it sounds like a good idea, the fact of the<br>
>> matter is that CentOS rebuilds from already built source RPMS. This<br>
>> is not the normal use case for Koji, where sources, patches, and<br>
>> specs are its input.<br>
> I don't believe that is true, releasing Red Hat built binaries would<br>
> be directly against the Red Hat licensing agreement.<br>
<br>
</div>Binaries? Where did I mention binary RPMS? Source RPMS == SRPMS,<br>
right? The source RPM (SRPM) is spit out from the same build process<br>
that makes the binary RPM (thus, why I called them 'already built').<br>
The input to building RPMS is in SOURCES and SPECS in the build tree;<br>
SRPMS are not the input, they are part of the output of the process and<br>
encapsulate the input to the process in a convenient and rebuildable<br>
wrapper that also holds some essential build information that is not<br>
found in the normal SOURCES and SPECS input.<br>
<div class="im"><br>
><br>
> C6 is/should be built from SRPMs, Johnny builds each package in his environment.<br>
<br>
</div>The environment used is the one built up by mock in the buildroot;<br>
sometimes some customizations have to be added to make this work<br>
(hand-injecting buildrequires, as Johnny mentioned, is part of the<br>
process; there are ways to automate 'hand' injection without modifying<br>
the source RPM (SRPM, if you prefer)). I've done this myself,<br>
rebuilding CentOS 5 on IA64, and it was educational.<br>
<br>
Koji is built to best handle the case for building from SOURCES and<br>
SPECS (which are in a revision control system, ideally), not from<br>
already built source RPMS (SRPMS). It will rebuild from SRPM, but it's<br>
overkill for that use case.<br>
<br>
Again, I say that from first-hand experience in actually doing a<br>
rebuild, this isn't speculation on my part here. Go back and read the<br>
archives; I was one who, until actually trying it, thought koji might be<br>
a good thing (it's in the archives, as I already said). I had to have<br>
it proven to me, and I proved it to myself that koji is overkill for<br>
this purpose.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
CentOS-devel mailing list<br>
<a href="mailto:CentOS-devel@centos.org">CentOS-devel@centos.org</a><br>
<a href="http://lists.centos.org/mailman/listinfo/centos-devel" target="_blank">http://lists.centos.org/mailman/listinfo/centos-devel</a><br>
</div></div></blockquote></div><br></div>