I had occasion to look at the valgrind use in spec files because we might have an architecture regression downstream. I noticed that a lot of packages have hard-coded lists of architectures on which valgrind is available. Starting with Fedora 24, this lists is also available in the %{valgrind_arches} macro provided by redhat-rpm-config.
%{valgrind_arches} is always safe to use if you do not run valgrind during build, but only need valgrind-devel because it accurately reflects the availability of these packages.
If you run valgrind during build (BuildRequires: valgrind), you may encounter scenarios where it is supported only on a subset of architectures for your tests due to valgrind limitations. Here is what we use in glibc to set the valgrind support status:
# Default: Always run valgrind tests if there is architecture support. %ifarch %{valgrind_arches} %bcond_without valgrind %else %bcond_with valgrind %endif # Restrict %%{valgrind_arches} further in case there are problems with # the smoke test. %if %{with valgrind} %ifarch ppc64 ppc64p7 # The valgrind smoke test does not work on ppc64, ppc64p7 (bug 1273103). %undefine with_valgrind %endif %endif
(There are probably ways to express this in a less clumsy fashion.)
The idea is to never go beyond the set of architectures listed in %{valgrind_arches}.
Thanks, Florian