But that would break the spec file. If I remove %{?_isa} and try to do rpmbuild --target i686 on the spec file, it will erroneously pass the buildrequires even if I don't have xz-devel(x86-32) installed.

SRPM installs don't check the SRPM requires, and the spec file contained in the SRPM doesn't have expanded macros. What's the motivation of this?

(In reply to David Shea from comment #1)
> But that would break the spec file. If I remove %{?_isa} and try to do
> rpmbuild --target i686 on the spec file, it will erroneously pass the
> buildrequires even if I don't have xz-devel(x86-32) installed.

You are not supposed to do it this way, you are supposed to use mock to build 32bit package in 32bit environment.

> SRPM installs don't check the SRPM requires, and the spec file contained in
> the SRPM doesn't have expanded macros. What's the motivation of this?

rpmbuild --rebuild won't work. Also your package is not compliant with packaging guidelines. Please see link.

(In reply to Igor Gnatenko from comment #2)
> (In reply to David Shea from comment #1)
> > But that would break the spec file. If I remove %{?_isa} and try to do
> > rpmbuild --target i686 on the spec file, it will erroneously pass the
> > buildrequires even if I don't have xz-devel(x86-32) installed.
> 
> You are not supposed to do it this way, you are supposed to use mock to
> build 32bit package in 32bit environment.

Why not allow both?

> > SRPM installs don't check the SRPM requires, and the spec file contained in
> > the SRPM doesn't have expanded macros. What's the motivation of this?
> 
> rpmbuild --rebuild won't work. 

--rebuild works fine.

[dshea@localhost rpmbuild]$ uname -m
i686
[dshea@localhost rpmbuild]$ rpm -qp --requires SRPMS/ghc-lzma-0.0.0.3-1.fc27.src.rpm | grep 64
xz-devel(x86-64)
[dshea@localhost rpmbuild]$ rpmbuild --rebuild SRPMS/ghc-lzma-0.0.0.3-1.fc27.src.rpm >/dev/null 2>&1
[dshea@localhost rpmbuild]$ echo $?
0


> Also your package is not compliant with
> packaging guidelines. Please see link.

I did see the link, and I'm saying the packaging guidelines are wrong and are making things worse.

> I did see the link, and I'm saying the packaging guidelines are wrong and are making things worse.

Then please work with Fedora Packaging Committee to fix this, but until it's resolved please fix package, it's breaking automated tools (in my case it is koschei).

https://pagure.io/packaging-committee

⋊> ~/r/SPECS rpmbuild -bs ./hello.spec --target i686                                                                                                                                                       17:45:00
Building target platforms: i686
Building for target i686
Wrote: /home/brain/rpmbuild/SRPMS/hello-1-1.fc28.src.rpm

⋊> ~/r/SPECS sudo dnf builddep /home/brain/rpmbuild/SRPMS/hello-1-1.fc28.src.rpm --assumeno | grep gcc                                                                                                     17:45:38
 gcc                      i686        8.0.1-0.9.fc28         rawhide       21 M
 libgcc                   i686        8.0.1-0.9.fc28         rawhide       85 k
 gcc                      x86_64      8.0.1-0.9.fc28         rawhide       22 M
 gcc-c++                  x86_64      8.0.1-0.9.fc28         rawhide       12 M
 gcc-gdb-plugin           x86_64      8.0.1-0.9.fc28         rawhide      117 k
 libgcc                   x86_64      8.0.1-0.9.fc28         rawhide       77 k
Operation aborted.

And then this exact srpm ends up in repositories. So guidelines are 100% correct.

The next cabal-rpm release should fix this for future btw.

I am happy to fix since this was caused by cabal-rpm.