On Wed, Sep 16, 2026 at 10:43 AM Michel Lind <[email protected]> wrote: > > Hi all, > > For background: back in January, Neal and I presented a kernel > refactoring proposal at CentOS Connect > https://cfp.fedoraproject.org/centos-connect-2026/talk/X9JHNV/ > > This is informed by our work in CentOS' Hyperscale SIG, which builds > faster-moving backports (many coming from Fedora) and rebuilds stock > CentOS Stream packages with additional features. So - some of our work > there could potentially feed back to Fedora; see my previous CentOS > Showcase talk for examples - > https://cfp.fedoraproject.org/centos-showcase-2024-11/talk/PTV8JM/ > > 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: > > - 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 > - 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*) > - 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. > - Also while kernel modules need to be specially signed for Secure > Boot, perf does not need to be! > - 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 > - 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. Justin > Best regards, > > -- > _o) Michel Lind > _( ) https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 > README: https://fedoraproject.org/wiki/User:Salimma#README -- _______________________________________________ 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
