On 12/22/2013 02:11 AM, Steven Crothers wrote:
> On Thu, Dec 19, 2013 at 11:22 AM, Lamar Owen <lowen@pari.edu> wrote:

>> While on the surface it sounds like a good idea, the fact of the
>> matter is that CentOS rebuilds from already built source RPMS. This
>> is not the normal use case for Koji, where sources, patches, and
>> specs are its input.
> I don't believe that is true, releasing Red Hat built binaries would
> be directly against the Red Hat licensing agreement.

Binaries?  Where did I mention binary RPMS?  Source RPMS == SRPMS,
right?  The source RPM (SRPM) is spit out from the same build process
that makes the binary RPM (thus, why I called them 'already built').
The input to building RPMS is in SOURCES and SPECS in the build tree;
SRPMS are not the input, they are part of the output of the process and
encapsulate the input to the process in a convenient and rebuildable
wrapper that also holds some essential build information that is not
found in the normal SOURCES and SPECS input.

>
> C6 is/should be built from SRPMs, Johnny builds each package in his environment.

The environment used is the one built up by mock in the buildroot;
sometimes some customizations have to be added to make this work
(hand-injecting buildrequires, as Johnny mentioned, is part of the
process; there are ways to automate 'hand' injection without modifying
the source RPM (SRPM, if you prefer)).  I've done this myself,
rebuilding CentOS 5 on IA64, and it was educational.

Koji is built to best handle the case for building from SOURCES and
SPECS (which are in a revision control system, ideally), not from
already built source RPMS (SRPMS).  It will rebuild from SRPM, but it's
overkill for that use case.

Again, I say that from first-hand experience in actually doing a
rebuild, this isn't speculation on my part here.  Go back and read the
archives; I was one who, until actually trying it, thought koji might be
a good thing (it's in the archives, as I already said).  I had to have
it proven to me, and I proved it to myself that koji is overkill for
this purpose.

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel