On 12/22/2013 01:13 AM, Steven Crothers wrote:
On Tue, Dec 17, 2013 at 5:53 PM, Johnny Hughes johnny@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@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.