[CCing Fedora rarely used kernel list] On 10/1/26 17:44, Justin Forbes wrote: > On Wed, Sep 16, 2026 at 10:43 AM Michel Lind <[email protected]> > wrote: >> For the particular case of perf, we think it might make sense to split >> out the packaging from the kernel and build it standalone, for the >> reasons below:
I understand the reasons from your POV. And I don't care too much (even if what I write below might sound overly again a standalone perf; sorry for that), but I fail somewhat to see how Fedora benefits from the split. >> - while perf is mostly stable on x86_64, on aarch64 it is still getting >> a lot of fixes. e.g. the last update I made incorporated 20 cs-etm >> fixes: >> https://gitlab.com/CentOS/Hyperscale/rpms/perf/-/commit/8f8b93b559f9204d1188be68c0acb912ec07a37d What does that mean in the end? Will the perf standalone release that is shipped be ahead, round about on-par, or behind the perf in the sources of the kernel that Fedora stable currently ships? If ahead: but it nevertheless is considered stable, yes? >> - perf build has some BuildRequires that are not needed for building >> the kernel itself. Isolating the builds help reduce the number of BRs >> needed on both sides (including, yes, *Java*) So the kernel build might be a bit faster, but two packages instead of one need to be build, which has overhead as well. So there is only a benefit if the separate perf is build a lot less, yes? >> - separating the two makes it easier for interested contributors to >> help out - the kernel.spec is huge and kernel-ark packaging takes a >> while to get used to. +1 OTOH some people might expect that the perf they get from Fedora always matches the kernel Fedora ships, as that is what everybody is doing right now. Wonder if breaking that expectation could lead to confusion, but well, guess I'm overly careful here, so feel free to ignore this. >> - Also while kernel modules need to be specially signed for Secure >> Boot, perf does not need to be! Yeah, but that was the case before that, so I wonder if that should be in this list. >> - one pain point we have is that perf headers inconsistently show up in >> kernel-headers. If, say from F46 onwards perf is shipped standalone and >> perf-devel is the only place that ships perf headers, we can at least >> stop special-casing this. see e.g. >> https://gitlab.com/CentOS/Hyperscale/rpms/perf/-/blob/8f8b93b559f9204d1188be68c0acb912ec07a37d/perf.spec#L269-278 Can/should this be fixed with our current packaging? >> - perf's maintainer (acme) has mentioned in the past that almost nobody >> consumed the standalone perf tarballs - indeed, 6.15 came out with a >> bug where some aarch64 headers were left out so the tarball cannot be >> used to build on that architecture. With a standalone packaging, like >> in Hyperscale, we can consume the upstream tarball, but fall back to >> using the full Linux tarball when necessary (or generating our own >> tarballs from specific Git tags; the makefile targets make this easy) >> >> Hoping to get some discussions going, and especially buy in from Justin >> Forbes (cc:ed) - if generally this seems like a good idea, we're going >> to submit a Change Proposal for Fedora 46. Anyone interested is welcome >> to join, we're hoping to have at least the two of us and Justin >> onboard. > > So here is my problem with it... You have to convince RHEL. Otherwise > I have to maintain it in the kernel spec for ELN and in Fedora as a > separate package. We tried for years to get kernel-tools/perf as a > separate package inside RHEL, and it was always shot down which is why > we eventually moved Fedora back into kernel. You might see if acme is > interested in fighting that fight. Perhaps he would have better luck > with perf specifically. If RHEL is willing, and we can rip it out of > the kernel spec completely, I am fine with this. If not though, we > essentially end up with 2 maintenance paths for perf and I am not > interested in that. The following should not block things, but I'll mention it: right now I regularly build vanilla kernels (including stable-rc and next) for https://copr.fedorainfracloud.org/groups/g/kernel-vanilla/coprs/ -- which often finds build errors in perf/libperf I report upstream, to prevent them from hitting Fedora later. That relies on the perf packaging in kernel.spec, so it would be a shame if that would go (but okay, other people then will likely run into and report that). Ciao, Thorsten -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
