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@xxxxxxxxxxxx> 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.
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
