Hi there!
I have a question about this review: https://bugzilla.redhat.com/show_bug.cgi?id=889261
Is it ok to havearched BuildRequires?
In my opinion they should NOT be arched, because of the reasons given in the comments of the bug.
Cheers, Björn
Hello,
On 13 June 2013 17:00, Björn Esser bjoern.esser@gmail.com wrote:
Hi there!
I have a question about this review: https://bugzilla.redhat.com/show_bug.cgi?id=889261
Is it ok to havearched BuildRequires?
In my opinion they should NOT be arched, because of the reasons given in the comments of the bug.
I had to face many reviews where I got unconsistent behaviour and answers, but in the end Michael Schwendt made it prefectly clear (at least for me) with a comment on a Review (comment #39 onwards):
https://bugzilla.redhat.com/show_bug.cgi?id=820544
I've seen this repeated over and over in reviews; I think the packaging guidelines should be made clearer regarding this.
Regards, --Simone
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Le 13/06/2013 17:00, Björn Esser a écrit :
Hi there!
I have a question about this review: https://bugzilla.redhat.com/show_bug.cgi?id=889261
Is it ok to havearched BuildRequires?
No BR should not be arched. They are created at .src.rpm creation time (so, according to the builder arch)
Remi.
In my opinion they should NOT be arched, because of the reasons given in the comments of the bug.
Cheers, Björn
-- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
On 13 June 2013 17:30, Remi Collet Fedora@famillecollet.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Le 13/06/2013 17:00, Björn Esser a écrit :
Hi there!
I have a question about this review: https://bugzilla.redhat.com/show_bug.cgi?id=889261
Is it ok to havearched BuildRequires?
No BR should not be arched. They are created at .src.rpm creation time (so, according to the builder arch)
Remi.
Exactly, here an example of a Koji build done with _isa'ed BuildRequires (taken from the link I've posted before):
$ rpm -qpR libguac-client-vnc-0.6.0-4.fc17.src.rpm cairo-devel(x86-64) gnutls-devel(x86-64) libguac-devel(x86-64) = 0.6.0 libvncserver-devel(x86-64) rpmlib(FileDigests) <= 4.6.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1
This means I can't rebuild the src.rpm on an i686. This is wrong.
Regards, --Simone
tor 2013-06-13 klockan 17:34 +0200 skrev Simone Caronni:
Exactly, here an example of a Koji build done with _isa'ed BuildRequires (taken from the link I've posted before):
$ rpm -qpR libguac-client-vnc-0.6.0-4.fc17.src.rpm cairo-devel(x86-64) gnutls-devel(x86-64) libguac-devel(x86-64) = 0.6.0 libvncserver-devel(x86-64) rpmlib(FileDigests) <= 4.6.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1
This means I can't rebuild the src.rpm on an i686. This is wrong.
If what you say above was true it would be a problem. But it doesn't work like that.
$ uname -p x86_64 $ rpm -q --requires -p globus-common-14.9-3.fc18.src.rpm | grep x86 globus-core(x86-32) >= 8 libtool-ltdl-devel(x86-32) $ rpm -q --whatprovides 'globus-core(x86-32)' 'libtool-ltdl-devel(x86-32)' inget paket tillhandahåller globus-core(x86-32) inget paket tillhandahåller libtool-ltdl-devel(x86-32) $ rpmbuild --rebuild globus-common-14.9-3.fc18.src.rpm
... build succeeds ... because the BRs needed on the build system's architecture are there
[ellert@localhost ~]$ rpm -q --whatprovides 'globus-core(x86-64)' 'libtool-ltdl-devel(x86-64)' globus-core-8.9-6.fc18.x86_64 libtool-ltdl-devel-2.4.2-7.fc18.x86_64
The bogus requires in the created source rpm is no reason to write a broken spec file.
Mattias
Am Donnerstag, den 13.06.2013, 19:09 +0200 schrieb Mattias Ellert:
tor 2013-06-13 klockan 17:34 +0200 skrev Simone Caronni:
Exactly, here an example of a Koji build done with _isa'ed BuildRequires (taken from the link I've posted before):
$ rpm -qpR libguac-client-vnc-0.6.0-4.fc17.src.rpm cairo-devel(x86-64) gnutls-devel(x86-64) libguac-devel(x86-64) = 0.6.0 libvncserver-devel(x86-64) rpmlib(FileDigests) <= 4.6.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1
This means I can't rebuild the src.rpm on an i686. This is wrong.
If what you say above was true it would be a problem. But it doesn't work like that.
$ uname -p x86_64 $ rpm -q --requires -p globus-common-14.9-3.fc18.src.rpm | grep x86 globus-core(x86-32) >= 8 libtool-ltdl-devel(x86-32) $ rpm -q --whatprovides 'globus-core(x86-32)' 'libtool-ltdl-devel(x86-32)' inget paket tillhandahåller globus-core(x86-32) inget paket tillhandahåller libtool-ltdl-devel(x86-32) $ rpmbuild --rebuild globus-common-14.9-3.fc18.src.rpm
... build succeeds ... because the BRs needed on the build system's architecture are there
[ellert@localhost ~]$ rpm -q --whatprovides 'globus-core(x86-64)' 'libtool-ltdl-devel(x86-64)' globus-core-8.9-6.fc18.x86_64 libtool-ltdl-devel-2.4.2-7.fc18.x86_64
The _isa-macro _ALWAYS_ evals x86-64 on x86_64, even if the binary-rpm is build against i686-devel/libs...
The bogus requires in the created source rpm is no reason to write a broken spec file.
What will break the spec by removing _isa-macro from BRs? Is there any PROVEN reason for this? I'm NOT talking about the final-Requires in spec.
Am Donnerstag, den 13.06.2013, 19:09 +0200 schrieb Mattias Ellert:
tor 2013-06-13 klockan 17:34 +0200 skrev Simone Caronni:
Exactly, here an example of a Koji build done with _isa'ed BuildRequires (taken from the link I've posted before):
$ rpm -qpR libguac-client-vnc-0.6.0-4.fc17.src.rpm cairo-devel(x86-64) gnutls-devel(x86-64) libguac-devel(x86-64) = 0.6.0 libvncserver-devel(x86-64) rpmlib(FileDigests) <= 4.6.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1
This means I can't rebuild the src.rpm on an i686. This is wrong.
If what you say above was true it would be a problem. But it doesn't work like that.
$ uname -p x86_64 $ rpm -q --requires -p globus-common-14.9-3.fc18.src.rpm | grep x86 globus-core(x86-32) >= 8 libtool-ltdl-devel(x86-32) $ rpm -q --whatprovides 'globus-core(x86-32)' 'libtool-ltdl-devel(x86-32)' inget paket tillhandahåller globus-core(x86-32) inget paket tillhandahåller libtool-ltdl-devel(x86-32) $ rpmbuild --rebuild globus-common-14.9-3.fc18.src.rpm
... build succeeds ... because the BRs needed on the build system's architecture are there
[ellert@localhost ~]$ rpm -q --whatprovides 'globus-core(x86-64)' 'libtool-ltdl-devel(x86-64)' globus-core-8.9-6.fc18.x86_64 libtool-ltdl-devel-2.4.2-7.fc18.x86_64
The _isa-macro _ALWAYS_ evals x86-64 on x86_64, even if the binary-rpm is build against i686-devel/libs...
Or to be more clear: If you build an rpm on x86_64 against i686 libs the resulting bin-rpm will _ALWAYS_ provide x86-64-arched.
The bogus requires in the created source rpm is no reason to write a broken spec file.
What will break the spec by removing _isa-macro from BRs? Is there any PROVEN reason for this? I'm NOT talking about the final-Requires in spec.
Sorry for the double post. :)
tor 2013-06-13 klockan 19:20 +0200 skrev Björn Esser:
What will break the spec by removing _isa-macro from BRs? Is there any PROVEN reason for this? I'm NOT talking about the final-Requires in spec.
It is VERY EASY to construct such an example.
Consider a package containing the following BRs:
BuildRequires: nss-devel >= 3.10 BuildRequires: openssl-devel BuildRequires: cppunit-devel BuildRequires: glibmm24-devel BuildRequires: libdb-cxx-devel
All the BRs are satisfied:
$ rpm -q --whatprovides nss-devel openssl-devel cppunit-devel glibmm24-devel libdb-cxx-devel nss-devel-3.14.3-2.fc18.i686 openssl-devel-1.0.1e-4.fc18.x86_64 cppunit-devel-1.12.1-8.fc18.x86_64 glibmm24-devel-2.34.1-1.fc18.x86_64 libdb-cxx-devel-5.3.21-3.fc18.i686
rpmbuild does not complain about missing BRs, but starts the build:
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.5K5NNA + umask 022 . . . checking for NSS... no configure: WARNING: Cannot locate nss lib configure: Looking for db_cxx.h in standard locations checking db_cxx.h usability... yes checking db_cxx.h presence... yes checking for db_cxx.h... yes configure: Looking for libdb_cxx.so or libdb_cxx.dylib in standard locations checking for main in -ldb_cxx... no . . . /usr/bin/ld: skipping incompatible /lib/libdb_cxx.so when searching for -ldb_cxx /usr/bin/ld: skipping incompatible /usr/lib/libdb_cxx.so when searching for -ldb_cxx /usr/bin/ld: cannot find -ldb_cxx collect2: error: ld returned 1 exit status . . . error: Bad exit status from /var/tmp/rpm-tmp.YFoBhh (%build)
RPM build errors: Bad exit status from /var/tmp/rpm-tmp.YFoBhh (%build)
With proper isa in BRs:
BuildRequires: nss-devel%{?_isa} >= 3.10 BuildRequires: openssl-devel%{?_isa} BuildRequires: cppunit-devel%{?_isa} BuildRequires: glibmm24-devel%{?_isa} BuildRequires: libdb-cxx-devel%{?_isa}
rpmbuild correctly detects the missing BRs:
error: Failed build dependencies: nss-devel(x86-64) >= 3.10 is needed by canl-c++-1.0.0-2.fc18.x86_64 libdb-cxx-devel(x86-64) is needed by canl-c++-1.0.0-2.fc18.x86_64
Mattias
Am Donnerstag, den 13.06.2013, 22:44 +0200 schrieb Mattias Ellert:
tor 2013-06-13 klockan 19:20 +0200 skrev Björn Esser:
What will break the spec by removing _isa-macro from BRs? Is there any PROVEN reason for this? I'm NOT talking about the final-Requires in spec.
It is VERY EASY to construct such an example.
Consider a package containing the following BRs:
BuildRequires: nss-devel >= 3.10 BuildRequires: openssl-devel BuildRequires: cppunit-devel BuildRequires: glibmm24-devel BuildRequires: libdb-cxx-devel
All the BRs are satisfied:
$ rpm -q --whatprovides nss-devel openssl-devel cppunit-devel glibmm24-devel libdb-cxx-devel nss-devel-3.14.3-2.fc18.i686 openssl-devel-1.0.1e-4.fc18.x86_64 cppunit-devel-1.12.1-8.fc18.x86_64 glibmm24-devel-2.34.1-1.fc18.x86_64 libdb-cxx-devel-5.3.21-3.fc18.i686
rpmbuild does not complain about missing BRs, but starts the build:
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.5K5NNA
- umask 022
. . . checking for NSS... no configure: WARNING: Cannot locate nss lib configure: Looking for db_cxx.h in standard locations checking db_cxx.h usability... yes checking db_cxx.h presence... yes checking for db_cxx.h... yes configure: Looking for libdb_cxx.so or libdb_cxx.dylib in standard locations checking for main in -ldb_cxx... no . . . /usr/bin/ld: skipping incompatible /lib/libdb_cxx.so when searching for -ldb_cxx /usr/bin/ld: skipping incompatible /usr/lib/libdb_cxx.so when searching for -ldb_cxx /usr/bin/ld: cannot find -ldb_cxx collect2: error: ld returned 1 exit status
So not the spec file is broken, but you actually do not have the libs needed for linking installed on your local machine... That's all. Just an improper build-environment.
No more to say about this here... Look at the guidelines:
https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_and_.25.7B...
Cheers, Björn
On Thu, 13 Jun 2013 22:44:53 +0200, Mattias Ellert wrote:
tor 2013-06-13 klockan 19:20 +0200 skrev Björn Esser:
What will break the spec by removing _isa-macro from BRs? Is there any PROVEN reason for this? I'm NOT talking about the final-Requires in spec.
It is VERY EASY to construct such an example.
Sure, that's the known corner-case for multiarch installations.
It's similar for any arch-conditional build requirements in spec files. They are a bit of a hindrance, since one cannot rely on a downloaded src.rpm's Requires being complete. Unless one rebuilds the src.rpm first and then proceeds with the changed list of possibly arch-specific Requires in the freshly built src.rpm (e.g. as Mock does it before fetching the build requirements). Only then one can query the src.rpm with tools to install a long list of needed builddeps.
Consider a package containing the following BRs:
BuildRequires: nss-devel >= 3.10 BuildRequires: openssl-devel BuildRequires: cppunit-devel BuildRequires: glibmm24-devel BuildRequires: libdb-cxx-devel
All the BRs are satisfied:
$ rpm -q --whatprovides nss-devel openssl-devel cppunit-devel glibmm24-devel libdb-cxx-devel nss-devel-3.14.3-2.fc18.i686 openssl-devel-1.0.1e-4.fc18.x86_64 cppunit-devel-1.12.1-8.fc18.x86_64 glibmm24-devel-2.34.1-1.fc18.x86_64 libdb-cxx-devel-5.3.21-3.fc18.i686
Except for the minimum build environment, such as glibc-devel.i686 and libstdc++-devel.i686, the compiler(s) and preprocessor(s). The build would fail later on. %_isa in BRs here is like band-aid for a more fundamental problem, and it adds even another problem.
Oh, btw, not even all -devel dependencies use %_isa yet. On a normal x86_64 installation, installing something -devel.i686 often pulls in x86_64 deps. For your example, nss-devel.i686 will do that, too. %_isa would be needed in many many more places for multiarch operation.
rpmbuild correctly detects the missing BRs:
error: Failed build dependencies: nss-devel(x86-64) >= 3.10 is needed by canl-c++-1.0.0-2.fc18.x86_64 libdb-cxx-devel(x86-64) is needed by canl-c++-1.0.0-2.fc18.x86_64
Don't we prefer clean build environments, such as constructed by Mock? I know some people use "setarch i686 rpmbuild ..." and "setarch i686 yum ...", which accesses the full i386 repos on x86_64 installations.
Conclusively, I understand what you like about %_isa in BR, but I think it doesn't improve much compared with the confusion it adds.
On 06/13/2013 08:20 PM, Björn Esser wrote:
Am Donnerstag, den 13.06.2013, 19:09 +0200 schrieb Mattias Ellert:
tor 2013-06-13 klockan 17:34 +0200 skrev Simone Caronni:
Exactly, here an example of a Koji build done with _isa'ed BuildRequires (taken from the link I've posted before):
$ rpm -qpR libguac-client-vnc-0.6.0-4.fc17.src.rpm cairo-devel(x86-64) gnutls-devel(x86-64) libguac-devel(x86-64) = 0.6.0 libvncserver-devel(x86-64) rpmlib(FileDigests) <= 4.6.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1
This means I can't rebuild the src.rpm on an i686. This is wrong.
If what you say above was true it would be a problem. But it doesn't work like that.
$ uname -p x86_64 $ rpm -q --requires -p globus-common-14.9-3.fc18.src.rpm | grep x86 globus-core(x86-32) >= 8 libtool-ltdl-devel(x86-32) $ rpm -q --whatprovides 'globus-core(x86-32)' 'libtool-ltdl-devel(x86-32)' inget paket tillhandahåller globus-core(x86-32) inget paket tillhandahåller libtool-ltdl-devel(x86-32) $ rpmbuild --rebuild globus-common-14.9-3.fc18.src.rpm
... build succeeds ... because the BRs needed on the build system's architecture are there
[ellert@localhost ~]$ rpm -q --whatprovides 'globus-core(x86-64)' 'libtool-ltdl-devel(x86-64)' globus-core-8.9-6.fc18.x86_64 libtool-ltdl-devel-2.4.2-7.fc18.x86_64
The _isa-macro _ALWAYS_ evals x86-64 on x86_64, even if the binary-rpm is build against i686-devel/libs...
Or to be more clear: If you build an rpm on x86_64 against i686 libs the resulting bin-rpm will _ALWAYS_ provide x86-64-arched.
No. %{_isa} evaluates to the target arch of the build:
[pmatilai@localhost SPECS]$ rpmspec -q --buildrequires rpm.spec|head -10 libdb-devel libdb-devel(x86-64) fakechroot redhat-rpm-config gawk elfutils-devel(x86-64) >= 0.112 elfutils-libelf-devel(x86-64) readline-devel(x86-64) zlib-devel(x86-64) nss-devel(x86-64) [pmatilai@localhost SPECS]$ rpmspec -q --buildrequires --target i686 rpm.spec|head -10 libdb-devel libdb-devel(x86-32) fakechroot redhat-rpm-config gawk elfutils-devel(x86-32) >= 0.112 elfutils-libelf-devel(x86-32) readline-devel(x86-32) zlib-devel(x86-32) nss-devel(x86-32)
- Panu -
On Thu, 13 Jun 2013 19:09:29 +0200, Mattias Ellert wrote:
tor 2013-06-13 klockan 17:34 +0200 skrev Simone Caronni:
Exactly, here an example of a Koji build done with _isa'ed BuildRequires (taken from the link I've posted before):
$ rpm -qpR libguac-client-vnc-0.6.0-4.fc17.src.rpm cairo-devel(x86-64) gnutls-devel(x86-64) libguac-devel(x86-64) = 0.6.0 libvncserver-devel(x86-64) rpmlib(FileDigests) <= 4.6.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1
This means I can't rebuild the src.rpm on an i686. This is wrong.
If what you say above was true it would be a problem. But it doesn't work like that.
True, it doesn't really work like that, but %_isa in BuildRequires adds a confusing problem nevertheless.
BuildRequires in the spec file become the src.rpm's Requires. If those Requires are arch-specific, you cannot use tools like yum-builddep or "rpm" to query the package's build requirements. You would need to reconstruct the src.rpm always for the target arch (not only if there are arch-conditional BuildRequires).
The src.rpm is built on an arbitrary build host, and Fedora publishes a single src.rpm build in the sources repo. It's just lame if the user of an x86_64 installation downloads src.rpm packages, which contain x86-32, ppc or other arch-specific dependencies. That doesn't add any value at all.
$ rpmbuild --rebuild globus-common-14.9-3.fc18.src.rpm
That doesn't evaluate the src.rpm's Requires as yum-builddep or "rpm -qpR" do. So, why obfuscate the BuildRequires and the src.rpm's Requires?
... build succeeds ... because the BRs needed on the build system's architecture are there
Nasty, isn't it? The package specifies '(x86-32)' requirements, but you've just built for '(x86-64)'.
On Thu, Jun 13, 2013 at 08:30:19PM +0200, Michael Schwendt wrote:
On Thu, 13 Jun 2013 19:09:29 +0200, Mattias Ellert wrote:
If what you say above was true it would be a problem. But it doesn't work like that.
True, it doesn't really work like that, but %_isa in BuildRequires adds a confusing problem nevertheless.
BuildRequires in the spec file become the src.rpm's Requires. If those Requires are arch-specific, you cannot use tools like yum-builddep or "rpm" to query the package's build requirements. You would need to reconstruct the src.rpm always for the target arch (not only if there are arch-conditional BuildRequires).
The src.rpm is built on an arbitrary build host, and Fedora publishes a single src.rpm build in the sources repo. It's just lame if the user of an x86_64 installation downloads src.rpm packages, which contain x86-32, ppc or other arch-specific dependencies. That doesn't add any value at all.
$ rpmbuild --rebuild globus-common-14.9-3.fc18.src.rpm
That doesn't evaluate the src.rpm's Requires as yum-builddep or "rpm -qpR" do. So, why obfuscate the BuildRequires and the src.rpm's Requires?
... build succeeds ... because the BRs needed on the build system's architecture are there
Nasty, isn't it? The package specifies '(x86-32)' requirements, but you've just built for '(x86-64)'.
The FPC discussed this today and added a prohibition to using %{_isa} in BuildRequires to the Guidelines:
https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_and_.25.7B...
Thanks to mschwendt for explaining the rationale so clearly.
-Toshio
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.
Mattias
On Thu, 13 Jun 2013 22:49:11 +0200 Mattias Ellert mattias.ellert@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.
Also, as is noted in the guidelines https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_and_.25.7B... if you use %_isa in the BuildRequires, then e.g. a srpm built on x86_64 won't work on i386.
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.
On Thu, 13 Jun 2013 22:44:53 +0200 Mattias Ellert mattias.ellert@fysast.uu.se wrote:
It is VERY EASY to construct such an example.
Consider a package containing the following BRs:
... which is the same case as here.
fre 2013-06-14 klockan 01:14 +0300 skrev Susi Lehtola:
On Thu, 13 Jun 2013 22:49:11 +0200 Mattias Ellert mattias.ellert@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... 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. Users rebuild packages on the same systems as they install binary packages - the same issues arise.
On Thu, 13 Jun 2013 22:44:53 +0200 Mattias Ellert mattias.ellert@fysast.uu.se wrote:
It is VERY EASY to construct such an example.
Consider a package containing the following BRs:
... which is the same case as here.
This new guideline is backwards. In order to avoid a few tiny glitches caused by rpmbuild doing something weird, you are forcing everyone to write severely broken spec files.
Mattias
On Fri, 14 Jun 2013 04:42:06 +0200 Mattias Ellert mattias.ellert@fysast.uu.se wrote:
fre 2013-06-14 klockan 01:14 +0300 skrev Susi Lehtola:
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.
A normal user doesn't rebuild packages on their own machines. And if they do, the normal thing to do is use mock, which works correctly.
If you rebuild packages, then you're probably enough an expert to see if your build environment is not fully operational.
Also, as is noted in the guidelines https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_and_.25.7B... 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.
... uhh, such as?
If you have %_isa in the buildrequires, then you're going to be plain and simple unable to run rpmbuild --rebuild srpm. What you need to do is unpack it and then build the spec, instead.
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. Users rebuild packages on the same systems as they install binary packages - the same issues arise.
Packages are rebuilt in mock.
On Thu, 13 Jun 2013 22:44:53 +0200 Mattias Ellert mattias.ellert@fysast.uu.se wrote:
It is VERY EASY to construct such an example.
Consider a package containing the following BRs:
... which is the same case as here.
This new guideline is backwards. In order to avoid a few tiny glitches caused by rpmbuild doing something weird, you are forcing everyone to write severely broken spec files.
Not using mock is going backwards by many years. If you don't use it, you might end up with packages that get configured in a different fashion: features that don't exist in the Fedora packages may be turned on by configure, if the necessary dependency is installed in your system.
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@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... 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.
On 06/13/2013 09:53 PM, Toshio Kuratomi wrote:
On Thu, Jun 13, 2013 at 08:30:19PM +0200, Michael Schwendt wrote:
On Thu, 13 Jun 2013 19:09:29 +0200, Mattias Ellert wrote:
If what you say above was true it would be a problem. But it doesn't work like that.
True, it doesn't really work like that, but %_isa in BuildRequires adds a confusing problem nevertheless.
BuildRequires in the spec file become the src.rpm's Requires. If those Requires are arch-specific, you cannot use tools like yum-builddep or "rpm" to query the package's build requirements. You would need to reconstruct the src.rpm always for the target arch (not only if there are arch-conditional BuildRequires).
The src.rpm is built on an arbitrary build host, and Fedora publishes a single src.rpm build in the sources repo. It's just lame if the user of an x86_64 installation downloads src.rpm packages, which contain x86-32, ppc or other arch-specific dependencies. That doesn't add any value at all.
$ rpmbuild --rebuild globus-common-14.9-3.fc18.src.rpm
That doesn't evaluate the src.rpm's Requires as yum-builddep or "rpm -qpR" do. So, why obfuscate the BuildRequires and the src.rpm's Requires?
... build succeeds ... because the BRs needed on the build system's architecture are there
Nasty, isn't it? The package specifies '(x86-32)' requirements, but you've just built for '(x86-64)'.
The FPC discussed this today and added a prohibition to using %{_isa} in BuildRequires to the Guidelines:
https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_and_.25.7B...
Thanks to mschwendt for explaining the rationale so clearly.
"You MUST NOT use arched BuildRequires. The arch ends up in the built SRPM but SRPMs need to be architecture independent. "
By this logic you should also ban arch-conditional BuildRequires. And a whole bunch of other similar constructs. Which is not going to work because those constructs are actually needed.
What's broken is the assumption that SRPM is a truly arch-independent entity when its not, and the source repository layout which stems from the assumption.
The only reliable way to evaluate build-requires is by parsing the spec for the build target architecture, ie 'yum-builddep foo.spec'.
- Panu -
On 06/14/2013 01:42 PM, Panu Matilainen wrote:
On 06/13/2013 09:53 PM, Toshio Kuratomi wrote:
On Thu, Jun 13, 2013 at 08:30:19PM +0200, Michael Schwendt wrote:
On Thu, 13 Jun 2013 19:09:29 +0200, Mattias Ellert wrote:
If what you say above was true it would be a problem. But it doesn't work like that.
True, it doesn't really work like that, but %_isa in BuildRequires adds a confusing problem nevertheless.
BuildRequires in the spec file become the src.rpm's Requires. If those Requires are arch-specific, you cannot use tools like yum-builddep or "rpm" to query the package's build requirements. You would need to reconstruct the src.rpm always for the target arch (not only if there are arch-conditional BuildRequires).
The src.rpm is built on an arbitrary build host, and Fedora publishes a single src.rpm build in the sources repo. It's just lame if the user of an x86_64 installation downloads src.rpm packages, which contain x86-32, ppc or other arch-specific dependencies. That doesn't add any value at all.
$ rpmbuild --rebuild globus-common-14.9-3.fc18.src.rpm
That doesn't evaluate the src.rpm's Requires as yum-builddep or "rpm -qpR" do. So, why obfuscate the BuildRequires and the src.rpm's Requires?
... build succeeds ... because the BRs needed on the build system's architecture are there
Nasty, isn't it? The package specifies '(x86-32)' requirements, but you've just built for '(x86-64)'.
The FPC discussed this today and added a prohibition to using %{_isa} in BuildRequires to the Guidelines:
https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_and_.25.7B...
Thanks to mschwendt for explaining the rationale so clearly.
"You MUST NOT use arched BuildRequires. The arch ends up in the built SRPM but SRPMs need to be architecture independent. "
By this logic you should also ban arch-conditional BuildRequires. And a whole bunch of other similar constructs. Which is not going to work because those constructs are actually needed.
What's broken is the assumption that SRPM is a truly arch-independent entity when its not, and the source repository layout which stems from the assumption.
Actually its not even the source repository layout which is broken (it'd be insane to duplicate all the source for every arch just because src.rpm headers differ between arches), its the assumption that the metadata from such a repository can meaningfully be used for evaluating build-requires that is broken.
While we're at this (again): there are no guarantees that even the payload of an src.rpm is arch-independent, its trivial to create constructs where included sources and patches differ depending on what architecture an src.rpm was built. If people are worrying about src.rpm arch independence, THAT is what should be banned in the guidelines.
- Panu -
On Fri, Jun 14, 2013 at 03:29:25PM +0300, Panu Matilainen wrote:
Actually its not even the source repository layout which is broken (it'd be insane to duplicate all the source for every arch just because src.rpm headers differ between arches), its the assumption that the metadata from such a repository can meaningfully be used for evaluating build-requires that is broken.
While we're at this (again): there are no guarantees that even the payload of an src.rpm is arch-independent, its trivial to create constructs where included sources and patches differ depending on what architecture an src.rpm was built. If people are worrying about src.rpm arch independence, THAT is what should be banned in the guidelines.
<nod> That sounds like a good thing regardless of the rest of the discussion and unlike contemplating conditionals on BuildRequires, there should be no place where conditionals on payload is needed (the conditional logic can be moved to %prep where the pieces of the payload are used instead).
Created a proposed draft here: https://fedorahosted.org/fpc/ticket/306
-Toshio
On Fri, 14 Jun 2013 09:27:25 -0700, Toshio Kuratomi wrote:
On Fri, Jun 14, 2013 at 03:29:25PM +0300, Panu Matilainen wrote:
Actually its not even the source repository layout which is broken (it'd be insane to duplicate all the source for every arch just because src.rpm headers differ between arches), its the assumption that the metadata from such a repository can meaningfully be used for evaluating build-requires that is broken.
While we're at this (again): there are no guarantees that even the payload of an src.rpm is arch-independent, its trivial to create constructs where included sources and patches differ depending on what architecture an src.rpm was built. If people are worrying about src.rpm arch independence, THAT is what should be banned in the guidelines.
<nod> That sounds like a good thing regardless of the rest of the discussion and unlike contemplating conditionals on BuildRequires, there should be no place where conditionals on payload is needed (the conditional logic can be moved to %prep where the pieces of the payload are used instead).
Created a proposed draft here: https://fedorahosted.org/fpc/ticket/306
It's a good addition to the guidelines. I could swear we've had it as a topic years ago, likely just in a discussion related to %ifarch x86_64 and ExcludeArch/ExclusiveArch usage.
On 06/13/2013 09:30 PM, Michael Schwendt wrote:
On Thu, 13 Jun 2013 19:09:29 +0200, Mattias Ellert wrote:
tor 2013-06-13 klockan 17:34 +0200 skrev Simone Caronni:
Exactly, here an example of a Koji build done with _isa'ed BuildRequires (taken from the link I've posted before):
$ rpm -qpR libguac-client-vnc-0.6.0-4.fc17.src.rpm cairo-devel(x86-64) gnutls-devel(x86-64) libguac-devel(x86-64) = 0.6.0 libvncserver-devel(x86-64) rpmlib(FileDigests) <= 4.6.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1
This means I can't rebuild the src.rpm on an i686. This is wrong.
If what you say above was true it would be a problem. But it doesn't work like that.
True, it doesn't really work like that, but %_isa in BuildRequires adds a confusing problem nevertheless.
BuildRequires in the spec file become the src.rpm's Requires. If those Requires are arch-specific, you cannot use tools like yum-builddep or "rpm" to query the package's build requirements. You would need to reconstruct the src.rpm always for the target arch (not only if there are arch-conditional BuildRequires).
The src.rpm is built on an arbitrary build host, and Fedora publishes a single src.rpm build in the sources repo. It's just lame if the user of an x86_64 installation downloads src.rpm packages, which contain x86-32, ppc or other arch-specific dependencies. That doesn't add any value at all.
$ rpmbuild --rebuild globus-common-14.9-3.fc18.src.rpm
That doesn't evaluate the src.rpm's Requires as yum-builddep or "rpm -qpR" do. So, why obfuscate the BuildRequires and the src.rpm's Requires?
No, rpmbuild does not use src.rpm requires for determining build-requires because they're no good for that. The requires of src.rpm only reflect what build-requires were active during the creation of that specific src.rpm file, not what its build-requires for some other build on other arch, different --with/--without switches etc might be.
... build succeeds ... because the BRs needed on the build system's architecture are there
Nasty, isn't it? The package specifies '(x86-32)' requirements, but you've just built for '(x86-64)'.
See above, you're misunderstanding the meaning of src.rpm requires.
- Panu -
On Fri, 14 Jun 2013 15:26:59 +0300, Panu Matilainen wrote:
The src.rpm is built on an arbitrary build host, and Fedora publishes a single src.rpm build in the sources repo. It's just lame if the user of an x86_64 installation downloads src.rpm packages, which contain x86-32, ppc or other arch-specific dependencies. That doesn't add any value at all.
$ rpmbuild --rebuild globus-common-14.9-3.fc18.src.rpm
That doesn't evaluate the src.rpm's Requires as yum-builddep or "rpm -qpR" do. So, why obfuscate the BuildRequires and the src.rpm's Requires?
No, rpmbuild does not use src.rpm requires for determining build-requires because they're no good for that.
But yum-builddep does evaluate them.
The requires of src.rpm only reflect what build-requires were active during the creation of that specific src.rpm file,
Which is nearly what I've been preaching. "The spec file's BuildRequires become the src.rpm's Requires" depending on the environment the src.rpm is built within.
And why collect "what build-requires were active during the creation of that specific src.rpm file" even when building a src.rpm with --nodeps?
Nasty, isn't it? The package specifies '(x86-32)' requirements, but you've just built for '(x86-64)'.
See above, you're misunderstanding the meaning of src.rpm requires.
That's friendly from you. I think they don't serve a useful purpose, if one must "recreate" them or ignore them in favour of working with only the spec file contents.
fre 2013-06-14 klockan 15:07 +0200 skrev Michael Schwendt:
On Fri, 14 Jun 2013 15:26:59 +0300, Panu Matilainen wrote:
No, rpmbuild does not use src.rpm requires for determining build-requires because they're no good for that.
But yum-builddep does evaluate them.
Then file a bug against yum-builddep for doing the wrong thing. That one tool is using some metadata for what it was not intended to be used is no argument for forcing the metadata to fit this tool at the expense of creating huge breakages elsewhere.
The requires of src.rpm only reflect what build-requires were active during the creation of that specific src.rpm file,
Which is nearly what I've been preaching. "The spec file's BuildRequires become the src.rpm's Requires" depending on the environment the src.rpm is built within.
And why collect "what build-requires were active during the creation of that specific src.rpm file" even when building a src.rpm with --nodeps?
You are correct that the requires recorded in the srpm are not really useful, and it is not usable for what you think it is usable. It might be an idea to file a feature request to rpmbuild to not include these requires in the srpm header, since it seems to just create confusion what they represent and what they can and can not be used for. If they were not there it would be obvious that they can not be used for anything reasonable.
Nasty, isn't it? The package specifies '(x86-32)' requirements, but you've just built for '(x86-64)'.
Which is not nasty at all, but what I expected to happen.
See above, you're misunderstanding the meaning of src.rpm requires.
That's friendly from you. I think they don't serve a useful purpose, if one must "recreate" them or ignore them in favour of working with only the spec file contents.
Mattias
On Fri, 14 Jun 2013 15:39:13 +0200, Mattias Ellert wrote:
fre 2013-06-14 klockan 15:07 +0200 skrev Michael Schwendt:
On Fri, 14 Jun 2013 15:26:59 +0300, Panu Matilainen wrote:
No, rpmbuild does not use src.rpm requires for determining build-requires because they're no good for that.
But yum-builddep does evaluate them.
Then file a bug against yum-builddep for doing the wrong thing.
Rejected. Sorry. I still think using %_isa in BR is the wrong thing to do for reasons other than querying downloaded src.rpms.
That one tool is using some metadata for what it was not intended to be used is no argument for forcing the metadata to fit this tool at the expense of creating huge breakages elsewhere.
We also run repoquery on remote "sources" repos to examine build requirements in src.rpm packages. That would be broken by %_isa, too. The occasional arch-conditional BR is worse enough already (since we try to build for all archs, and we even track ExcludeArch usage).
"yumdownloader --resolve --source …" is another tool that evaluates src.rpm metadata without rebuilding them for the target arch.
The requires of src.rpm only reflect what build-requires were active during the creation of that specific src.rpm file,
Which is nearly what I've been preaching. "The spec file's BuildRequires become the src.rpm's Requires" depending on the environment the src.rpm is built within.
And why collect "what build-requires were active during the creation of that specific src.rpm file" even when building a src.rpm with --nodeps?
You are correct that the requires recorded in the srpm are not really useful, and it is not usable for what you think it is usable.
This is not about "what I think" but about what has been done so far by people and by tools. It is not a problem for me to adjust my work-flow for every src.rpm and either reconstruct it _always_ or have any tools parse only the spec file. Before considering adding %_isa to BuildRequires, existing tools and repo metadata ought to be changed, please.
On 06/14/2013 04:07 PM, Michael Schwendt wrote:
On Fri, 14 Jun 2013 15:26:59 +0300, Panu Matilainen wrote:
The src.rpm is built on an arbitrary build host, and Fedora publishes a single src.rpm build in the sources repo. It's just lame if the user of an x86_64 installation downloads src.rpm packages, which contain x86-32, ppc or other arch-specific dependencies. That doesn't add any value at all.
$ rpmbuild --rebuild globus-common-14.9-3.fc18.src.rpm
That doesn't evaluate the src.rpm's Requires as yum-builddep or "rpm -qpR" do. So, why obfuscate the BuildRequires and the src.rpm's Requires?
No, rpmbuild does not use src.rpm requires for determining build-requires because they're no good for that.
But yum-builddep does evaluate them.
Sure does, but that doesn't make it the right thing to do for src.rpm's built for another architecture, such as often is the case in Fedora source repositories. Perhaps I should patch it to at least warn about such a case, although IIRC that's not possible for the repository metadata which fakes the architecture of src.rpm's to "src" which is not correct either.
The requires of src.rpm only reflect what build-requires were active during the creation of that specific src.rpm file,
Which is nearly what I've been preaching. "The spec file's BuildRequires become the src.rpm's Requires" depending on the environment the src.rpm is built within.
Well, yes. And exactly because of that, the src.rpm's requires are not cross-arch usable: the spec can contain things like
%ifarch ppc64 BuildRequires: ppc64-utils %endif
...which might or might not end up in the src.rpm, depending on which arch it was created on, and the requires of that src.rpm are only valid for the same architecture the src.rpm was created on, not any other.
And why collect "what build-requires were active during the creation of that specific src.rpm file" even when building a src.rpm with --nodeps?
s/active/parsed/ might be closer to the mark.
Nasty, isn't it? The package specifies '(x86-32)' requirements, but you've just built for '(x86-64)'.
See above, you're misunderstanding the meaning of src.rpm requires.
That's friendly from you. I think they don't serve a useful purpose, if one must "recreate" them or ignore them in favour of working with only the spec file contents.
Mind you, I'm not arguing about the usefulness (or lack of thereof) of the src.rpm metadata, I'm just explaining what it is and what it is not, because there clearly is a lot of confusion and misconceptions about it.
- Panu -
On 14/06/2013 17:07, Michael Schwendt wrote:
On Fri, 14 Jun 2013 15:26:59 +0300, Panu Matilainen wrote:
[... skip ...] The requires of src.rpm only reflect what build-requires were active during the creation of that specific src.rpm file, ...
Which is nearly what I've been preaching. "The spec file's BuildRequires become the src.rpm's Requires" depending on the environment the src.rpm is built within.
Michael,
building 32-bit software on x86_64 systems is *very* important, completely legal, and fully supported use case, right ? (RedHat-provided gcc, binutils, etc for x86_64 always support 32-bit targets.)
Given that, on x86_64 system, obviously,
* building 32-bit `foo' package requires 32-bit glibc-devel. * building 64-bit `foo' package requires 64-bit glibc-devel.
Given that, how would I write a single spec for these to work on the same x86_64 system :
$ rpmbuild --rebuild foo.src.rpm $ rpmbuild --rebuild --target i686 foo.src.rpm
without arched BR's ?
Dont' mention mock and preparing same-target build environment. If rpmbuild had not designed for [target arch != build arch] condition, it wouldn't has had `--target' option.
As regards storing build requirements in *.src.rpm files. It's wrong asking
- What this .src.rpm requires ?
Correct asking is
- What this .src.rpm requires when building *for <some particular> arch* ?
Kind regards, Konstantin Andreev.
On Wed, 28 Jan 2015 02:01:29 +0400, Konstantin Andreev wrote:
On 14/06/2013 17:07, Michael Schwendt wrote:
On Fri, 14 Jun 2013 15:26:59 +0300, Panu Matilainen wrote:
[... skip ...] The requires of src.rpm only reflect what build-requires were active during the creation of that specific src.rpm file, ...
Which is nearly what I've been preaching. "The spec file's BuildRequires become the src.rpm's Requires" depending on the environment the src.rpm is built within.
Michael,
building 32-bit software on x86_64 systems is *very* important, completely legal, and fully supported use case, right ? (RedHat-provided gcc, binutils, etc for x86_64 always support 32-bit targets.)
Given that, on x86_64 system, obviously,
- building 32-bit `foo' package requires 32-bit glibc-devel.
- building 64-bit `foo' package requires 64-bit glibc-devel.
Given that, how would I write a single spec for these to work on the same x86_64 system :
$ rpmbuild --rebuild foo.src.rpm $ rpmbuild --rebuild --target i686 foo.src.rpmwithout arched BR's ?
There have been several comments and explanations both in the original thread on this list and also the FPC ticket:
https://fedorahosted.org/fpc/ticket/303
Please read the longer reply from Panu in there.
No need to address me directly in a reply, because I'm not the decisive force with regard to how Fedora handles this or will handle this when the tool-chain gets changed to support this properly.
Correct asking is
- What this .src.rpm requires when building *for <some particular> arch* ?
It's an unfortunate start IMO, if you tell what's "wrong" and what's "correct" without presenting an example of how you use existing src.rpms _today_. How do you install needed build requirements? Manually based on what rpmbuild says is missing? (You cannot run setarch i686 yum ... because it will switch to different repos!)
So far, there is a _single_ src.rpm built on _any_ arch and made available in a _single_ repo for all archs. Depending on where this src.rpm was built, you would get x86-64 Requires on an i686 installation, for example. You cannot use these Requires stored in the src.rpm _without_ rebuilding it for the target arch. Rebuilding the src.rpm would need to become a MUST. You could also not repoquery source repos reliably anymore about dependencies without adding wildcards (a sources repoquery on whatrequires foo-devel would fail).
On Wed, 2015-01-28 at 02:01 +0400, Konstantin Andreev wrote:
On 14/06/2013 17:07, Michael Schwendt wrote:
On Fri, 14 Jun 2013 15:26:59 +0300, Panu Matilainen wrote:
[... skip ...] The requires of src.rpm only reflect what build-requires were
active during the creation of that specific src.rpm file, ...
Which is nearly what I've been preaching. "The spec file's
BuildRequires become the src.rpm's Requires" depending on the environment the src.rpm is built within.
Michael,
building 32-bit software on x86_64 systems is *very* important, completely legal, and fully supported use case, right ? (RedHat-provided gcc, binutils, etc for x86_64 always support 32-bit targets.)
Fully supported by whom, and in what capacity? This is not an idle/weird question, there are a lot of things that an "upstream" will support that Fedora/FPC do not. For instance, lots of upstreams think that static linking or bundling is a great idea. This is not the view of Fedora policy though.
Given that, on x86_64 system, obviously,
- building 32-bit `foo' package requires 32-bit glibc-devel.
- building 64-bit `foo' package requires 64-bit glibc-devel.
And "BuildRequires: glibc-devel" will do the right thing with mock, koji and yum-builddep. And just as relevantly "BuildRequires: glibc-devel%{_isa}" will not DTRT with any of those tools ... and those are the tools Fedora uses.
Given that, how would I write a single spec for these to work on the same x86_64 system :
$ rpmbuild --rebuild foo.src.rpm $ rpmbuild --rebuild --target i686 foo.src.rpmwithout arched BR's ?
You can't, and if you have some environment that needs to do that but doesn't need createrepo'd data of the BuildRequires then feel free to use arch'd BuildRequires. But Fedora doesn't use that environment, and does need createrepo'd data of the BuildRequires.
Dont' mention mock and preparing same-target build environment.
Why? That's the recommend way of doing local builds in Fedora.
If rpmbuild had not designed for [target arch != build arch] condition, it wouldn't has had `--target' option.
Again, this is a difference between what options upstream gives you and supports vs. what Fedora supports. rpm also supports --relocate, but that isn't valid in Fedora either.
As regards storing build requirements in *.src.rpm files. It's wrong asking
- What this .src.rpm requires ?
Correct asking is
- What this .src.rpm requires when building *for <some particular> arch* ?
Not in Fedora, in Fedora the target arch and the generic .src.rpm are the inputs. If you want to change this you need to speak to rel-eng/FESCO.
packaging@lists.fedoraproject.org
-
Björn Esser -
James Antill -
Konstantin Andreev -
Manuel Wolfshant -
Mattias Ellert -
Michael Schwendt -
Panu Matilainen -
Remi Collet -
Simone Caronni -
Susi Lehtola -
Toshio Kuratomi