Potential changes to systemd RPM macros

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux