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
