Re: [PATCH] spec: Do not disable some systemd units of newly split package
On Thu, Jun 08, 2023 at 12:35:45PM -0600, Jim Fehlig wrote:
On 6/8/23 08:52, Andrea Bolognani wrote:
> On Wed, Jun 07, 2023 at 04:31:36PM +0200, Martin Kletzander wrote:
> > +# Since this was split into a different package, a transparent update for the
> > +# virtproxyd units could actually disable an already configured ones
> > +# (e.g. virtproxyd-tls.socket) as %systemd_post runs `systemctl preset` if
this
> > +# is an installation (and is skipped on update). So skip this step for those
> > +# that need an extra setup to work since they will most likely not be preset
to
> > +# enabled, but that is up to the point of the distribution.
> > +%libvirt_daemon_systemd_post virtproxyd
>
> It's actually worse than that: if you are using the monolithic daemon
> on a distro that uses split daemons by default (e.g. Fedora),
Why use the monolithic and split daemons together? Shouldn't we discourage
such configuration? :-)
Whether to use monlithic or split daemons is ultimately a choice of
the local admin. Fedora defaults to split daemons, but switching back
to a "classic" monolithic deployment is still a fully supported
scenario.
Additionally, the current default has been adopted relatively
recently, and we have made the explicit decision *not* to migrate
existing installations over. So if your OS was originally installed
before split daemons had become the default and you've been dutifully
upgrading to subsequent Fedora releases without ever reinstalling,
then you're also going to be using the monolithic daemon.
> Basically we need to detect if we're installing the
> libvirt-daemon-proxy package as part of an upgrade and *not touch
> anything* if that's the case. I'm not sure how that can be achieved
> in the context of RPM scriptlets though, or if it's even possible :(
It's possible to determine a package install vs upgrade, but IIUC the
problem can occur when installing or upgrading libvirt-daemon-proxy. The
usual 'if [ $1 -ge 2 ]' for upgrade-only actions wont work in that case.
Yeah, exactly: it's easy to detect whether a single package is being
upgraded or installed from scratch, but in this case we would need to
know whether libvirt-daemon is being upgraded in the scriptlet for
libvirt-daemon-proxy, which I don't think is possible.
Can we somehow enforce that libvirt-daemon is fully configured before
libvirt-daemon-proxy? If so, we could create a witness file based on
the information we need in libvirt-daemon's %post, look at it in
libvirt-daemon-proxy's %post and base our decision on that.
Can we skip the 'libvirt_daemon_systemd_post_inet' if
virtproxyd is enabled?
Or adjust the macro to not 'systemd_post' sockets that are already enabled?
Sockets *and* services. We don't want virtproxyd.service to be
started on boot if libvirtd.service will also be.
--
Andrea Bolognani / Red Hat / Virtualization