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 _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
