[CentOS-devel] a public build tool for seven

On 12/22/2013 01:13 AM, Steven Crothers wrote:
> On Tue, Dec 17, 2013 at 5:53 PM, Johnny Hughes <johnny at centos.org> wrote:
>> On 12/17/2013 04:50 PM, Steven Crothers wrote:
>>> Why not run a CentOS Koji, or perhaps request access/space to the
>>> Fedora Koji (unlikely)?
>>>
>>> Koji is the "standard" both for Fedora and EPEL, and I once heard it's
>>> used internally at Red Hat as well, as far as to what extent, I have
>>> no idea.
>>> Steven Crothers
>>> steven.crothers at gmail.com
>> Because we don't use koji, and I don't think we want to
> While I appreciate brevity and the ability to get the point without
> project manager jibjab, that answer really leaves a lot to be desired
> for.
>
> SRPMs come in, RPMs come out.
>
> Seems like the perfect solutions to me.
>
> All you're doing is rebuilding, there is no secret sauce involved. Why
> not make it easier? It'll dep solve, build everything in proper order
> and build individual mock roots for each and every RPM ensuring that
> the build is clean.
>
> Curious as to why you don't want to.

Well, I can tell you that it does not seem like the perfect solution to
us .. at least not to me.  The goal here is to call mock with an SRPM. 
Koji can do that, so can the system we use.  We have a system that calls
mock and we have other automation around that system that has taken us
years to make.  We have no intention (at this point) in redesigning our
system.  Koji did not exist when we started our method to create builds.

If we were creating a system from scratch now, then maybe we might use
koji .. then again, maybe not.

We think our entire system, from end to end, works better than koji for
our process ... unless we are convinced otherwise, we won't be changing.

How is our process different ... the vast majority of SRPMs that we get
do not need modification and an RPMs get built directly from the
upstream SRPMs, submitted to our build system.  A relatively small
number of SRPMs need to be changed, but even these changed SRPMs are not
in a git (or other VCS tree) where we modify it as we go along.  We need
to import the new SRPM into in over top our old one (which will revert
our changes from before and add in the new changed from upstream), make
some predetermined changes to the new code that we have figured out
before (which were already in the old version, but were just overwritten
by the import) and make sure those changes work in the new code, then
create an SRPM and send it to the build.

We also may encounter SRPMs with "hidden build requirements", where
there is something in the upstream build root that is not called out in
the SRPM.  For example, upstream may have package_xyz in their build
root, but it is not as a BuildRequires in the SRPM.  We need a way to
get package_xyz into the build root, for building this SRPM, BUT we
don't want to change the SRPM to include it as a build requires, since
our goal is to not change SRPMS.  We feed back to upstream that
package_xyz needs to be a BuildRequires for that SRPM (via
bugzilla.redhat.com) and change our configuration to build with
package_xyz in the buildroot in the interim.  An example is that in the
past, sqlite-devel and crash-devel was required to be added into the EL5
build tree to build the systemtap SRPM.

So some of our packages are built directly from the upstream SRPMS, some
are modified in a VCS (either git or svn depending on EL5 or EL6) and
the modified SRPMs are built, and still other SRPMs need hidden build
requirements solved.  We have a process by which we accomplish this that
we don't think needs to be modified at this time.  Maybe we can be
convinced otherwise, but for now we like what we have.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20131223/d3cdcabd/attachment-0001.sig>