Hi Andrea, On Thu, Jul 20, 2023 at 07:40:08AM -0700, Andrea Bolognani wrote: > 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. This is a known problem. We've been usually dealing with it in an ad-hoc manner using a %trigger. I'll paste some docs from another email below, but that is complex and generally far from ideal. It'd be nice to have a clean solution for this. Another issue is that our guidelines don't mention the issue at all, so if people don't know about it, it's easy to fall into the trap. So there's certainly space for improvement here ;) > 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. Systemd macros are maintained upstream. So if you have patches/suggestions/etc., they should be filed upstream. I looked briefly at your links [4,5] but it seems very libvirt-specific and it's hard to see the full plan without context. Please file a pull request upstream and it'll be easier to discuss there. There're also people from other distros there. One immediate comment is that systemd macros have been reworked to restart everything in %posttrans using a single operation. I.e. various per-package macros mark services with "needs-restart", and then in %posttrans a single 'systemctl reload-or-restart --marked' does the deed. It seems your macros reimplement the previous behaviour of individual restarts, and we wouldn't want to go back to that. -- >From https://lists.fedoraproject.org/archives/list/kexec@xxxxxxxxxxxxxxxxxxxxxxx/message/CD6E7VD4TWMKQEDM4ETGZCU5OX53NVEH/: > -%post > +%post -n kdump-tools > # Initial installation > %systemd_post kdump.service This one is tricky. %systemd_post presets the service on "first installation", which is actually the first the time package is installed. I.e. it unfortunately also would execute the preset on upgrades that split out a subpackage, because as far as rpm is concerned, this is the initial installation of that subpackage. The righteous way to solve this would be something like this: %triggerprein -n kdump-tools -- kexec-tools < 2.0.26-8 touch %{_localstatedir}/lib/rpm-state/kexec-tools.no-preset %post -n kdump-tools rm %{_localstatedir}/lib/rpm-state/kexec-tools.no-preset 2>/dev/null && return 0 # Initial installation %systemd_post kdump.service A bit of a bother, but at least nobody will be suprised by kdump.service changing state. -- Zbyszek _______________________________________________ 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
