https://bugzilla.redhat.com/show_bug.cgi?id=1118740 Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(vpavlin@xxxxxxxxx | |m) | --- Comment #23 from Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> --- > What that does require is for systemd to handle all previously installed (but > deferred) presets in %post [ $1 == 1 ]. How exactly? We could add 'if[ $1 == 1 ]; then systemctl preset-all; fi', which would call presets for all packages that were installed previously. Unfortunately it would also undo any enablement/disablement that was done previously. We don't keep any state that would tell us for which packages systemd preset should be called, instead every package does the call itself on initial install. But it'd be really unexpected to have a normal system without systemd installed in the initial transaction, so maybe that's OK. We'd have to document the fact that initial installation of systemd removes unit enablement configuration. We already call 'udevadm hwdb --update' and 'journalctl --update-catalog' and 'systemd-tmpfiles --create' in systemd %post, so other calls to systemd functionality that happen in package scriptlets should be covered. (In reply to Yaakov Selkowitz from comment #22) > > Recommends: systemd > > OrderWithRequires(post): systemd > > OrderWithRequires(preun): systemd > > OrderWithRequires(postun): systemd I'd rather turn this into another macro (%systemd_ordering ?). > That may very well be a better approach overall, but I'm not sure about the > Recommends:, I think Suggests: or nothing at all would make more sense in at > least some cases. Either would work. Recommends is likely to be ignored when creating a minimal image anyway. But Recommends has the advantage that systemd would be pulled in when creating a chroot with dnf. PS. I'll remove needinfo, because Vaclav retired the package in pkgdb last year. Let's keep the bug open for discussion. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/package-review@xxxxxxxxxxxxxxxxxxxxxxx