https://bugzilla.redhat.com/show_bug.cgi?id=2079784 --- Comment #15 from Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> --- > What about 'Provides:systemd-boot-signed(%{efi_arch)) = %version-%release' ? Added: +Provides: systemd-boot-signed-%{efi_arch} = %version-%release and in the systemd pr: +Provides: systemd-boot-unsigned-%{efi_arch} = %version-%release I guess that using -%{efi_arch} has the advantage that (%{efi_arch}) could be mistaken and/or interfere with (%{_isa}). -- > There's nothing in that post that refuted or even addresses any of my points above. You wrote "it will by definition have different CVEs and different code", and that post and the rest of the thread discusses how systemd-boot and bootctl actually share code. Even more importantly, they share implementation logic (even if sometimes we need to have two separate implementations), so the same bugs could and in practice do affect both. The rest of your analysis is based on this flawed assumption. > If three's a CVE that's against systemd it covers all of systemd and hence the CVE still applies to sd-boot even if the code is unaffected I don't know what you're trying to say. CVEs generally apply to some specific part of the code, which means that (for a project like systemd that builds multiple binaries), it applies to one or more binaries. When analyzing a CVE, figuring out *where* it applies is generally one of the first steps. So we will know if the boot loader binaries can be affected, and whether to update them or not. Whether the packages are separate or not would only matter if we were mechanically creating an update for every CVE without any scope analysis. > With a different repo it can release when it has new features/fixes True. > and be independent bumps which is especially useful for dealing with CVEs. Actually we retain the ability to do independent bumps even with the split as it is implemented now. -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2079784 _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-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/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
