From: Emanuele Giuseppe Esposito on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1805489153 Ok so to make a summary, this could be a possible solution. We want to create sub-rpms so that: * `kernel-uki-virt-$uname.$distro.$arch` has the UKI. This is already implemented. Now, suppose we have an UKI `$UKI`. In the concrete example, it will be `virt`. We would have the following sub-rpms: * `kernel-addons-$UKI-common-$uname.$distro.$arch` has the $UKI global addons signed by $UKI key. * `kernel-addons-$UKI-$uname.$distro.$arch` has the $UKI local addons signed by $UKI key. But since at the moment we don't care about local addons, let's leave this as TODO. * `kernel-addons-$UKI-debug-$uname.$distro.$arch` has the unsigned debug addons. Or alternatively `kernel-addons-$UKI-unsigned-$uname.$distro.$arch`. Or this can be shared by all UKIs, we can discuss about this later. Also this as TODO. Therefore we are left with $UKI global addons. We have a config-like structure, which could be `redhat/addons/$distro/$UKI/global or local/$arch/addon_name.conf` (file content will stay the same as it is now, line starting with # are comment and the rest is command line). `redhat/addons/$distro/$UKI` will be packed as SourceNNN. When processing the $UKI package, kernel.spec fetches SourceNNN/global/$arch. My script takes the files in there and creates `addon_name-global-$UKI.$distro.$arch.addon.efi` to be packed in `kernel- addons-$UKI-common-$uname.$distro.$arch` that will install it in `/usr/lib/linux/` Example: `virt` UKI and `something` UKI. Resulting theoretical sub-rpms: * kernel-uki-virt * kernel-addons-virt-common * kernel-addons-virt * kernel-uki-virt-debug * kernel-something-virt * kernel-addons-something-common * kernel-addons-something * kernel-uki-something-debug Resulting actual sub-rpms after this MR: * kernel-uki-virt * kernel-addons-virt-common * kernel-something-virt * kernel-addons-something-common And concretely now we only have the `virt` UKI. Does this sound correct? @berrange @vkuznets @prudo1 -- _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-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/kernel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
