In order to run systemtap, it needs to be built with the same "bitness" as the target kernel. For the typical ppc64 kernel, we need the ppc64 build of systemtap{,-runtime} in the compose, and not the ppc variant. (The same packaging glitch was fixed for RHEL* recently.) This problem also appears in fc7 test releases.
David?
I know nothing of systemtap but I expect Frank is speaking truth. Can we add it to the whitelist so it's included in the compose? After F7 release we can do cunning things like making the 32-bit systemtap conflict with a virtual 'CPU.ppc64' -- but just having it available will suffice for now, right?
Yes, but with your rpm patch, the 32bit binary will win if both are installed, and thus not usable. Both have to be available as the 64bit systemtap won't even install on a ppc32 install.
True, but a 64-bit user can just remove the 32-bit version and reinstall the 64-bit version. It's not perfect, but overall the situation (with the RPM patch) is a lot better than it was before. And just having the 64-bit systemtap _available_ for installation is an improvement over F7t4. After F7 we can make the 32-bit version conflict with either a virtual CPU.ppc64 or just with kernel-ppc64. We don't want to go there yet though. (I'll file the yum bug in a moment). FWIW I had this problem with kexec-tools too. My preferred fix was just to make the 32-bit userspace work with the 64-bit kernel :)
I've added systemtap(-runtime) for the ppc64 multilib whitelist.