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(a)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...
> 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.