Hello and apologies for the delayed response; I have been out of office for a couple of weeks.
On Fri, Dec 17, 2021 at 8:00 AM Neal Gompa <ngomp...@gmail.com> wrote: > > On Fri, Dec 17, 2021 at 5:45 AM Ben Cotton <bcot...@redhat.com> wrote: > > > > https://fedoraproject.org/wiki/Changes/Keylime_subpackaging_and_agent_alternatives > > > > == Summary == > > The [https://src.fedoraproject.org/rpms/keylime keylime] package will > > be split into subpackages per role (agent, registrar, verifier, and > > admin components), while allowing the alternative agent implementation > > in Rust. > > > > == Owner == > > * Name: [[User:Scorreia| Sergio Correia]] > > * Email: scorr...@redhat.com > > > > * Name: [[User:Ueno| Daiki Ueno]] > > * Email: du...@redhat.com > > > > > > == Detailed Description == > > The current [https://keylime.dev/ Keylime] package available in Fedora > > provides all the components as a single package. To support the usage > > scenarios where only agent or management component is deployed on a > > specific host, we plan to split the package into subpackages per role. > > This change also enables the alternative Keylime agent implementation > > in Rust, which will eventually be preferred over the Python > > implementation. > > > > > > == Benefit to Fedora == > > This makes it easier to deploy Keylime agent in IoT or Fedora CoreOS > > spins and thus enable remote attestation without installing full > > dependencies of Keylime. > > > > == Scope == > > * Proposal owners: > > ** The keylime package will provide subpackages (keylime-agent, > > keylime-registrar, etc) > > ** The keylime package will be a meta package that will install all > > the subpackages > > ** The Rust based [https://github.com/keylime/rust-keylime agent] will > > be packaged along with its build dependencies > > ** Both keylime-agent implementations, one written in Python, the > > other written in Rust, will be selectively installable through > > [https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/ > > alternatives] or a similar mechanism > > > > Alternatives only make sense if parallel installability is desirable. > It doesn't sound like that is the case for this situation. > > Instead, you probably want to leverage RPM's installable alternatives > framework, which we use for PipeWire/PulseAudio and > pipewire-media-session/wireplumber. > Yeah, you are right; looking at your pipewire/pulseaudio example, it looks like what we want to do here. > For PipeWire/PulseAudio, the pipewire-pulseaudio and pulseaudio > packages had the following stanzas added: > > Provides: pulseaudio-daemon > Conflicts: pulseaudio-daemon > > For pipewire-media-session/wireplumber, those packages had the > following stanzas added: > > Provides: pipewire-session-manager > Conflicts: pipewire-session-manager > > The Provides+Conflicts on a single virtual name makes it so RPM knows > that those packages are equivalent providers, but only one of them can > be present on a system at a time. Attempting to install the other > would trigger a Conflicts, and you'd need to use "dnf swap" to switch > implementations. > > For your case, each Keylime agent package would have the following stanzas: > > Provides: keylime-tpm-agent > Conflicts: keylime-tpm-agent > > Those two stanzas tell RPM that keylime-agent-python and > keylime-agent-rust are equivalent, but conflicting providers of > "keylime-tpm-agent" and will only allow one or the other. > Thanks for the help here, and I will update the proposal to reflect your suggestion. Best Regards, Sergio _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
