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