[Fedora-packaging] arched BuildRequires?

[Manuel Wolfshant]

On 06/14/2013 05:42 AM, Mattias Ellert wrote:
> fre 2013-06-14 klockan 01:14 +0300 skrev Susi Lehtola:
>> On Thu, 13 Jun 2013 22:49:11 +0200
>> Mattias Ellert <mattias.ellert at fysast.uu.se> wrote:
>>> tor 2013-06-13 klockan 11:53 -0700 skrev Toshio Kuratomi:
>>>
>>>> The FPC discussed this today and added a prohibition to using
>>>> %{_isa} in BuildRequires to the Guidelines:
>>> Please reconsider this. A specfile without isa in BuildRequires is
>>> broken for exactly the same reason a binary rpm without isa in
>>> Requires is broken. Not all packages the provide the BR are suitable
>>> to fulfil it for the purpose of providing the resources necessary for
>>> doing the build.
>> The difference is that BuildRequires are only relevant on the build
>> system, where the correct architecture will be pulled in by the
>> BuildRequire. Remember, the build environment is prepped separately for
>> each build.
> I disagree with this. The BuildRequires are relevant for users wanting
> to rebuild packages on their own machines. Without isa this is severely
> broken.
>
>> Also, as is noted in the guidelines
>> https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_and_.25.7B_isa.7D
>> if you use %_isa in the BuildRequires, then e.g. a srpm built on x86_64
>> won't work on i386.
> This "won't work" is an exaggeration. There are a few glitches in some
> cases, but these are minor compared to the problems you get by not
> having proper BRs by not using isa.
>
>> For binary RPMs the situation is very different - you can't assume
>> anything about the state of the system. %_isa is needed for the case
>> where the system already has, say libfoo(x86-32) installed, and then
>> you install foo(x86-64) that dlopens libfoo. You need the %_isa in the
>> binary rpm requires to make sure that the compatible library gets
>> installed, although the libfoo package already is present on the system.
> You can not make assumptions about what packages a user has installed on
> the system where packages are built.
Exactly. Especially if you take into account that the sane way to build 
packages in a controlled environment is to use mock.



> Users rebuild packages on the same
> systems as they install binary packages - the same issues arise.
This is definitely not true. No sane person would keep all the needed 
-devel packages on the final machines where the built binaries will be 
used. I for one have completely different machines in terms of hardware 
and installed packages. The build farm ( where mock is used ) has 
significantly different memory and storage requiements compared to the 
production machines. And except for python and maybe perl, no build 
tools ( especially gcc, make & Co.) exist on the production machines.