[scl.org] Setting SCL RPM build options in COPR?

[Honza Horak]

On 09/18/2017 07:29 AM, Nick Coghlan wrote:
> Using RPM List Builder, I have a recipe for bootstrapping the initial
> set of sclo-python RPMs locally in mock:
> https://github.com/ncoghlan/pyscl-devel/
> 
> Before building that in the CentOS build system, I'm aiming to first
> do a preview build in COPR:
> https://copr.fedorainfracloud.org/coprs/ncoghlan/sclo-python-preview/
> 
> However, I've hit a problem in translating the local mock build
> command into a copr-cli build command, which is that the local builds
> are relying on the ability to pass in arbitrary RPM build options to
> specify the right settings for "scl" and "vendorscl".
> 
> As far as I can tell, that isn't going to work for COPR or CBS, since
> they expect to be able to just build the component as is, and don't
> offer the ability to configure the build step.
> 
> So I have two questions:
> 
> 1. Have I missed something, and it's actually possible to pass extra
> RPM build options for COPR builds? (it would make sense to me that I
> can't - the build isn't going to very repeatable if I can run it with
> different non-default settings each time)

That's correct, I think your point about reproducibility is actually the 
reason why it works this way.

> 2. Assuming I haven't missed anything, how do the *default* values for
> "scl" and "vendorscl" actually get set?

We can kinda control what packages are part of the minimal buildroot for 
every copr or cbs tag -- for SCL case there is the <scl>-build package 
that sets this 'scl' macro. You can add more macros if you like and they 
will be defined at a time a particular SRPM/RPM is built. By that trick 
and changing what macros are defined in <scl>-build, you may basically 
build more variants of a single SRPM and produce different output.

Honza

> Cheers,
> Nick.
>