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.
_______________________________________________
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg
