| Message ID | 87o8fdwmdn.fsf@gmx.com |
|---|---|
| Headers | show |
| Series | Update libvirt and friends. | expand |
Pierre Langlois writes: > Hello Guix! > > This is a patch series that updates libvirt to 7.1.0, now using the > meson build system, and then updates a few dependent packages as well. > > Getting libvirt to build and then work properly was quite tedious, given > that we have to build it so that the binaries refer to /etc and /var at > runtime, while we set the prefix to the package output. This was > relatively straight-forward with the old build system, but with meson I > ended up having to patch meson.build so that: > > - It allows for localstatedir to not be relative to the prefix. And > prevent it from trying to create empty directories in /var during > installation. > > - It allows installing configurations, in /gnu/...-libvirt-7.1.0/etc/, > but still refer to the system /etc at runtime. An alternative would > be to not do any of the installation steps for /etc files, but doing > that was more intrusive a change to the build system, and having > those configurations installed could be useful examples, or referred > to be services. > > Other than that, the rest is pretty straight-forward. I've tested this > using the libvirt service and virt-manager, making sure I could still > boot a VM. It's all working fine for me, although my use-case is quite > simple, just the defaults: Just after sending this, I realized we actually had a system test for the libvirt service, that works too :-).
Hi Pierre, Pierre Langlois <pierre.langlois@gmx.com> skribis: > This is a patch series that updates libvirt to 7.1.0, now using the > meson build system, and then updates a few dependent packages as well. > > Getting libvirt to build and then work properly was quite tedious, given > that we have to build it so that the binaries refer to /etc and /var at > runtime, while we set the prefix to the package output. This was > relatively straight-forward with the old build system, but with meson I > ended up having to patch meson.build so that: > > - It allows for localstatedir to not be relative to the prefix. And > prevent it from trying to create empty directories in /var during > installation. > > - It allows installing configurations, in /gnu/...-libvirt-7.1.0/etc/, > but still refer to the system /etc at runtime. An alternative would > be to not do any of the installation steps for /etc files, but doing > that was more intrusive a change to the build system, and having > those configurations installed could be useful examples, or referred > to be services. > > Other than that, the rest is pretty straight-forward. I've tested this > using the libvirt service and virt-manager, making sure I could still > boot a VM. It's all working fine for me, although my use-case is quite > simple, just the defaults: > > (services (cons* > (service libvirt-service-type > (libvirt-configuration > (unix-sock-group "libvirt"))) > ...)) > > Let me know what you think and if that's good enough to apply! The > definition is a bit more hacky than I'd like, so any ideas to improve it > would be great. AFAICS it all works like a charm, including the system test :-), so I went ahead and applied the whole series. Thank you! Ludo’.
Hello Guix! This is a patch series that updates libvirt to 7.1.0, now using the meson build system, and then updates a few dependent packages as well. Getting libvirt to build and then work properly was quite tedious, given that we have to build it so that the binaries refer to /etc and /var at runtime, while we set the prefix to the package output. This was relatively straight-forward with the old build system, but with meson I ended up having to patch meson.build so that: - It allows for localstatedir to not be relative to the prefix. And prevent it from trying to create empty directories in /var during installation. - It allows installing configurations, in /gnu/...-libvirt-7.1.0/etc/, but still refer to the system /etc at runtime. An alternative would be to not do any of the installation steps for /etc files, but doing that was more intrusive a change to the build system, and having those configurations installed could be useful examples, or referred to be services. Other than that, the rest is pretty straight-forward. I've tested this using the libvirt service and virt-manager, making sure I could still boot a VM. It's all working fine for me, although my use-case is quite simple, just the defaults: --8<---------------cut here---------------start------------->8--- (services (cons* (service libvirt-service-type (libvirt-configuration (unix-sock-group "libvirt"))) ...)) --8<---------------cut here---------------end--------------->8--- Let me know what you think and if that's good enough to apply! The definition is a bit more hacky than I'd like, so any ideas to improve it would be great. Thanks, Pierre Pierre Langlois (4): gnu: libvirt: Update to 7.1.0. gnu: python-libvirt: Update to 7.1.0. gnu: libvirt-glib: Update to 4.0.0. gnu: virt-manager: Update to 3.2.0. gnu/local.mk | 2 +- .../libvirt-create-machine-cgroup.patch | 48 -------- .../libvirt-do-not-create-var-dirs.patch | 30 +++++ gnu/packages/virtualization.scm | 106 ++++++++---------- 4 files changed, 76 insertions(+), 110 deletions(-) delete mode 100644 gnu/packages/patches/libvirt-create-machine-cgroup.patch create mode 100644 gnu/packages/patches/libvirt-do-not-create-var-dirs.patch