On Fri, Jul 14, 2023 at 08:25:57AM -0700, Andrea Bolognani wrote: > 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. If we at least start the discussion, we can get feedback on whether the idea is likely to gain traction, or there are other things we have overlooked With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
