Packaging golang for secondary architectures, go-srpm-macros

[Petr Pisar]

On 2015-07-09, Jan Chaloupka <jchaloup at redhat.com> wrote:
> 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.
>
That's good to know. But then I don't understand this guide lines rule
<https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#BuildRequires_and_.25.7B_isa.7D>:

You MUST NOT use arched BuildRequires. The arch ends up in the built
SRPM but SRPMs need to be architecture independent. For instance, if you
did this:

# Example of what *not* to do
BuildRequires:  python%{?_isa} >= 2.7

Then the SRPM that is built in Fedora would have one of these
Requirements depending on what builder the SRPM was created on:

python(x86-32) >= 2.7
# or
python(x86-64) >= 2.7

This would prevent yum-builddep or similar tools that use the SRPM's
requirements from operating correctly.


Is the only issue that SRPM repository which is populated from packages built
on random architecture (the (1) step)) will get random data?

Then the original question would suffer from the same problem.

Then either we should ban it too or claim that SRPM repository is not
reliable and remove the ban from the guide lines.

-- Petr