[libvirt PATCH 0/8] rpm: Fix handling of systemd units

[Andrea Bolognani]

On Fri, Jul 14, 2023 at 04:02:30PM +0100, Daniel P. Berrangé wrote:
> I don't have an objection to the conceptual approach.
>
> My concern is about where the solution is applied and divergance from
> Fedora guidelines.
>
> The long term direction of Fedora / RPM has been to reduce the number
> of scriptlets required to be explicitly listed in package specfiles, by
> having RPM globally apply script logic for all content in certain given
> directories. If we're using standard Fedora macros, then we'd not expect
> to see problems if the macros get changed to adapt to new approaches,
> but if we're going our own way all bets are off.
>
> The current macros we're using are specified in the Fedora packaging
> guidelines:
>
>   https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_systemd

That's *mostly* correct, but as noted in one of the commit messages
we have already been forced to implement a bunch of additional custom
logic because the standard macros simply don't cover all the
scenarios we need.

> and their impl is provided by systemd upstream itself:
>
>   https://github.com/systemd/systemd/blob/main/src/rpm/macros.systemd.in
>
> The problems described do not appear to be things unique to libvirt.

They're not! That said, somehow libvirt frequently manages to push
boundaries in ways that are fairly uncomfortable :)

> IOW, I think the problem needs to be raised & addressed in context of
> the Fedora and systemd communities, rather than having libvirt diverge
> from normal Feora packaging practice.

I absolutely agree with you, and I fully intend to push for these
changes (or comparable ones) to be implemented in systemd, where they
belong and from where they can benefit more than just us.

That said, timing is a concern. Fedora 38 and RHEL 9.2 are both on
libvirt 9.0.0 at the moment, so they haven't been hit by the issue
yet, but new releases for both are just around the corner and I have
little confidence that we'd be able to push the necessary changes
through in time. So a local solution seems like the only plausible
way that we can avoid breaking user's deployments.

-- 
Andrea Bolognani / Red Hat / Virtualization