Noarch with unported dependencies
Sometimes you are working on a noarch package that can only run in locations that a different, arched package builds on. This is common for packages written in a scripting language which depend on the language's interpreter package, for instance. If the arched package that your package deps on isn't available on all architectures Fedora (or EPEL) targets you run into a situation where you may need to exclude your package from certain architectures' yum repositories or prevent it from building on certain architectures in the buildsystem.
Requires
When your package needs the problematic dependency at runtime but not at build time then you only need to keep it from entering the yum repositories for that architecture. There is a relatively simple workaround for this:
BuildArch: noarch
# List the arches that the dependent package builds on below
ExclusiveArch: %{ix86} %{arm} x86_64 noarch
Sometimes a language runtime you are packaging for will provide a macro for the arches it's available on, for instance, %{nodejs_arches}. If it does exist, then you can use something like ExclusiveArch:%{nodejs_arches} noarch in your spec file. Take a look at the Guidelines for the language to see if such a macro exists.
BuildRequires
Building a noarch package that has a dependency that isn't available on all arches is much more difficult to handle. There is no way to specify architectures to exclude building on that koji will apply to a noarch package build. Koji attempt to use any available builder to build a noarch package. You have two choices in this case:
If the dependent package is missing on an architecture that has few hosts in the buildsystem (for instance, it does build on x86, x86_64, and arm but does not build on ppc64) then you can decide to ignore the problem and simply submit the builds. Whenever the builds are attempted on the problematic architecture they will fail and you will have to remember to resubmit them and hope koji will assign the build to a different arch.
If the dependent package is missing on an architecture that has many hosts in the buildsystem (for instance, it does not build on arm) then you will be spending a large amount of time resubmitting builds. In this case it is better to make your package architecture specific. Koji will then be able to use your package's ExclusiveArch: tag to tell what architectures cannot be used to build:
# Cannot build as noarch until foo-lang is ported to arm.
# Comment out BuildArch: noarch for now.
# BuildArch: noarch
ExclusiveArch: %{ix86} x86_64