Bug 1332198

Hello Colin,

what we are currently doing is adding alternative build sources instead of just accepting already built srpms (by URL/upload methods). For example, you can use MockSCM source and point it to a Git/SVN repository. When you then build from this source, what happens is that our dist-git importer will fetch the content of the pointed-to repository and makes srpm out of it (by using Mock SCM plugin). This resulting srpm is then uploaded into dist-git for our builders to build out of it. The same goes for Tito, PyPI, and RubyGem (coming soon) sources. We always need some tool (tito, pyp2rpm, gem2rpm respectively) that "compiles" the raw sources into a source-rpm. After the consequent import of this srpm into dist-git, the rpm build process stays the same no matter what the srpm build source (URL/upload/Tito/MockSCM/PyPI/RubyGem) was.

So we are happy for capable srpm makers but cgwalters/rpmdistro-gitoverlay also seems to change the way the rpms are built. This is probably something we cannot incorporate while keeping our infrastructure simple enough.

rdgo does exactly that, generate SRPMs before handing them off to mockchain.  Right?

Is there a command to rdgo that says "just give me srpm from the sources, don't build any rpms"?

I could add one, however - things get tricky, because in order to "build" the SRPMs in some cases, we may actually need built RPMs from the chain in the buildroot.

This actually occurs for my use backporting some of the Fedora golang on CentOS, and this is why rpmdistro-gitoverlay does what Koji does and generates the SRPM in a buildroot.

How would we handle that case?

This is where the (S)RPM model is overly painful.

It'd be a lot saner to not even need the SRPM phase - store the macros in a git repository, and use something like `rpmbuild --rcfile`?

For anyone who wants precompiled RPMs until this review completes, the COPR link: https://copr.fedorainfracloud.org/coprs/walters/git-evtag/

Er, sorry wrong bug.

(In reply to Colin Walters from comment #4)
> I could add one, however - things get tricky, because in order to "build"
> the SRPMs in some cases, we may actually need built RPMs from the chain in
> the buildroot.
> 
> This actually occurs for my use backporting some of the Fedora golang on
> CentOS, and this is why rpmdistro-gitoverlay does what Koji does and
> generates the SRPM in a buildroot.
> 
> How would we handle that case?

It would be possible to add an option to specify some repo baseurl(s) for our importing procedure running on a dist-git machine so that the needed rpms are accessible through http. 

But still, as I see it, we already have the functionality of rdgo covered by our Tito (and also Mock SCM) import methods together with configurable auto-rebuilds (implemented by github webhooks). At least, the functionality that covers some essential use-cases of our users.

My overall impression is that rdgo is a parallel project that we can draw an inspiration from rather than a tool that could fit somewhere in the COPR infrastructure.

There's a lot of overlap in different components for sure.  I would also be OK if COPR didn't end up using any of the rdgo code, but implemented some similar features.

tito is okay but it's more designed as a tool to feed the current dist-git/koji combination, whereas rdgo is more oriented towards *replacing* it.  Which is actually closer to what COPR is.

Some critical features for me are (as the rdgo README says):

 - Declarative state synchronization rather than API driven - if I drop a build out of the overlay, we stop shipping it.  If I say "build this earlier git commit", it works, rather than possibly picking up an older but higher version build that happened to be built before
 - Pull from both upstream git and dist-git git automatically
 - Support git submodules (tito doesn't)

Declarative state synchronization seems to be a long way from where we are standing now. The other two points might be feasible to get implemented in foreseeable future.

If presence of any of the mentioned features in COPR is of the importance to you or to your particular use-case, fill a descriptive RFE for it.

("wontfix" here addresses only the rpmdistro-gitoverlay integration.)

A build model similar to what rdgo provides would be a very nice addition imho:

Say I want to provide copr builds from some upstream project, using my own spec file. So, basically to git repos are involved: The upstream git, and my git hosting the specfile.

Unless I am mistaken, there's currently no way to do this other than merging the upstream source into my git, so that in the end, the project files and the spec file end up in the same repository, right?

Are there any plans to support such a model with a clear separation between upstream and spec file?