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. Best regards, -- _o) Michel Lind _( ) https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 README: https://fedoraproject.org/wiki/User:Salimma#README
signature.asc
Description: This is a digitally signed message part
-- _______________________________________________ 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
