Hi, this requires a bit of background, so please bear with me :)
Earlier this year, the libvirt project changed its RPM package to be more granular[1] as a step towards a future where the legacy monolithic daemon (libvirtd) is completely gone. This change has happened upstream, but the Fedora package uses the same spec file so it was quickly reflected in Rawhide. As part of this change virtproxyd, a service which has historically been part of the libvirt-daemon package, has been moved to the newly-introduced libvirt-daemon-proxy package. More recently we have realized that, despite our care in trying to ensure smooth upgrades, splitting the package this way has unfortunately caused unintended consequences[2][3]. Specifically, since the libvirt-daemon-proxy package is a completely new one as far as RPM is concerned, all its systemd units will get presets applied during %post. In at least two completely valid deployment scenarios, this results in some amount of brokenness due to local configuration changes made by the admin getting discarded. In order to avoid this problem, I have implemented a new set of RPM macros[4][5] that base the decision of whether presets should be applied for a systemd unit not on whether the package that contains them is being newly installed, but rather on whether the unit itself existed on the system before package installation. This should address not only the scenario of services being split off to separate packages, but also the one where an existing package starts shipping additional services. Now, since this is clearly not a libvirt-specific issue, I believe this approach should be adopted across Fedora by way of these macros (or comparable ones) being added to systemd. Packages would have to migrate from the old macros over time, and at some point it should be possible to get rid of them entirely. Note that openSUSE already has its own distro-specific RPM macros for dealing with systemd units, and in fact the approach that I have implemented is partially inspired by theirs. Ideally, we'd be able to collaborate with them to create a single set of macros that lives in systemd and satisfies the needs of both Fedora and openSUSE. The problem is that Fedora 39 and RHEL 9.3 are fast approaching and, if we don't do anything about this issue before then, a subset of libvirt users will see their deployments broken after upgrade. In the interest of avoiding that, I would prefer to get the libvirt-specific version of the macros merged as soon as possible, and focus on upstreaming the work all the way to systemd as a follow-up. Does this plan sound reasonable to the Fedora community? Are there any serious concerns regarding the approach taken for the macros that would cause them to be considered a complete no-go? Any scenarios that I might have missed while implementing them? Thanks for your patience in reading this far :) and looking forward to your feedback! [1] https://listman.redhat.com/archives/libvir-list/2023-January/237059.html [2] https://bugzilla.redhat.com/show_bug.cgi?id=2210058 [3] https://listman.redhat.com/archives/libvir-list/2023-June/240226.html [4] https://listman.redhat.com/archives/libvir-list/2023-July/240723.html [5] https://listman.redhat.com/archives/libvir-list/2023-July/240729.html -- Andrea Bolognani / Red Hat / Virtualization _______________________________________________ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
