perf package

[Roland McGrath]

After talking to Kyle on IRC a bit, I committed some changes to how we
build and package perf.  Kyle didn't so much endorse a plan as first say
he just didn't care what I shoved up there, and then suggest a new and
different shape that might be more pleasing than what I'd proposed.

So what I've committed and built (2.6.35-0.29.rc4.git0.fc14) is entirely
contrary to what I described before.  It's all easy to revert or change
if we don't like it.  We have no new kernel-perf subpackage that I
talked about.

Instead, the perf package is no longer noarch and no longer a wrapper
script.  That package has the perf binary and its man pages and
attendant hooey, just as if it were any random userland package.

I made it use tools/perf/Makefile's 'make install', so we get everything
them geniuses upstream think we want.  Various things (I don't know
what) that I presume didn't work before should work now, since we
package /usr/libexec/perf-core with various internal scripts that are
for whatever.  perf is now in /usr/bin rather than /usr/sbin, cause
bindir is what upstream thinks we want and I ain't the kind to argue.

This might mean some kind of pain for wrong-dominant multilib distros,
but those people can pummel us later.  Or maybe ppc32-built perf can
talk to a ppc64 kernel OK, hell if I know.

This lovely plan follows from the new presumption that perf binaries and
kernels of the present and future can handle each other sanely enough.
acme said this was true, and you can assign all your bugs about perf vs
kernel mismatches to him. ;-)

Complaints and suggestions welcomish.  
But, it done built now, so, you know, by default, we're shippin' it.


Thanks,
Roland