On Sat, 22 Feb 2025 at 21:55, Benson Muite <benson_muite@xxxxxxxxxxxxx> wrote:
Fedora has a policy to support only one kernel. Projects such as OpenHarmony support multiple kernels to enable reuse of components on devices with a wide range of compute capabilities - in particular mobile and edge devices. Is this something Fedora would consider doing? This would potentially benefit spins aimed for mobile and desktop use.
Most of the 'policy' is due to resource constraints of several sorts:
1. The build system allows for only one src.rpm of a 'name' at a time. This means any alternative kernel needs to either be built from that one src.rpm (which it has been in the far past I think), OR has to be a seperate src.pm have a name like kernel-lts-5_5 or something similar.
2. Building kernels is not a fast process. It has to build successfully on 4 to 5 architectures with any failure on that arch to kill the entire build. Having more kernels which need to be built from a single src.rpm makes this more fragile. Having more kernels from different rpms is better but still fragile
3. There is a very limited number of 'kernel' developers who work on Fedora. Dealing with the current 1 kernel is a full time job for them as while it is fairly upstream it does break in odd ways at times.
4. The kernel is in a unique security space dealing with both specific signing for secure boot but also general trust issues from the community. This limits the number of people who can work on the kernel space.
The solution to all of these problems is what others have mentioned: COPR. People who want to build LTS kernels, specific tuned items, etc can do so in a COPR and share that work with any others who are interested in trying it out. It won't have secure signing but for a lot of the tuning or other items, you probably turned it off. It also allows people to work on it when they can versus needing to find 1-3 full time people per kernel build per day for say a couple of LTS kernels.
Benson
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
