On Tue, Jul 25, 2023 at 10:55:54AM -0400, Andrea Bolognani wrote:
On Mon, Jul 24, 2023 at 04:36:07PM +0200, Martin Kletzander wrote:On Fri, Jul 14, 2023 at 04:39:38PM +0200, Andrea Bolognani wrote: > The current implementation pretty much assumes that targets > where modular daemons are the default will stick with that > configuration, as will targets where they're not, or that > changes to these defaults will be performed by the admin after > the packages have been installed. > > This is unnecessarily limiting: for example, on a target that > defaults to using the monolithic daemon, it's entirely possible > to create a local preset such as > > # /etc/systemd/system-preset/00-virt.preset > disable libvirtd.service > disable libvirtd*.socket > enable virtqemud.service > > to opt into a modular daemon deployment. The opposite is of > course also true. We shouldn't get in the way of these > reasonable use cases. I could thought only of one thing that could be a problem, tracked it down and then found out it will not be an issue. So I think this is fine.Out of curiosity, what scenario did you have in mind?
One thing that makes different sense to me every time I read it is the way the presets override themselves. The wording from systemd.preset(5) is a bit confusing sometimes, but I read it again and properly and found out everything is fine. Don't worry about it =)
To be honest I've only verified that this works correctly with my new macros, which at this point of the series are not yet used. I'm fairly confident the same applies even to the standard macros, but I'll check that too for completeness' sake.
It'd be nice to get some real-life testing, but issue that this is trying to fix is not going to manifest in rolling distros any more anyway, that one we need to test for, but we know how. If there's more we'll see it in the distros for which this is actually fixing the existing issue(s).
-- Andrea Bolognani / Red Hat / Virtualization
Attachment:
signature.asc
Description: PGP signature
