Packaging golang for secondary architectures, go-srpm-macros

Jan Chaloupka jchaloup at redhat.com
Thu Jul 9 13:21:54 UTC 2015



On 07/09/2015 03:07 PM, Dan HorĂ¡k wrote:
> On Thu, 9 Jul 2015 10:49:01 +0000 (UTC)
> Petr Pisar <ppisar at redhat.com> wrote:
>
>> On 2015-07-09, Jan Chaloupka <jchaloup at redhat.com> wrote:
>>> # Define arches for PA and SA
>>> %golang_arches   %{ix86} x86_64 %{arm}
>> [...]
>>> Recommended use in spec file:
>>> 1) To choose the correct compiler:
>>> %ifarch %{golang_arches}
>>> BuildRequires: golang
>>> %else
>>> BuildRequires: gcc-go >= %{gccgo_min_vers}
>>> %endif
>>>
>> This will not work. A source package is built on random architecture,
>> thus using %ifarch to define BuildRequire will provide random results.
>>
>> (And maybe while building a source package, the RPM architecture is
>> redefined to `noarch' value.)
> I don't have any real analysis at hand, but we use %ifarch-ed
> BuildRequires regularly and it works as expected. Secondary arches do
> builds from imported srpms that are created on primary arches. A problem
> is when Source or Patch are %ifarch-ed and this is forbidden by the
> Guidelines.

Talking to Dan Mach (CC'ing) he confirmed the srpm is rebuilt on a 
concrete architecture before rpm is built. So the workflow is:
1) build srpm on random architecture
2) once rpm is about to be built on a concrete architecture (noarch or 
arch-dep), rebuild srpm on the architecture
3) build rpm from the rebuilt srpm.

> And I think you are right with the "noarch" set as the architecture
> when srpm is being created in the BuildSRPMFromSCM task.
>
>
> 		Dan


More information about the devel mailing list